US  Army  Corps 


of  Engineers® 


Engineer  Research  and 
Development  Center 


Design  Review  and  Checking  System 
(DrChecks) 

E.  William  East,  Jeffrey  G.  Kirby,  and  Jana  Kelly  September  2001 


Approved  for  public  release;  distribution  is  unlimited. 


20011016  071 


US  Army  Corps 
of  Engineers® 

Engineer  Research  and 
Development  Center 


Design  Review  and  Checking  System 
(DrChecks) 

E.  William  East,  Jeffrey  G.  Kirby,  and  Jana  Kelly  September  2001 


Approved  tor  public  release;  distribution  is  unlimited. 


2 


ERDC/CERL  SR-01-20 


Foreword 


This  study  was  conducted  for  the  U.S.  Army  Corps  of  Engineers  under  Military 
Interdepartmental  Purchase  Request  (MIPR)  WX3JR902219476,  “DrChecks- 
FYOl-Alaska.”  The  technical  monitor  was  Rick  D.  Dahnke,  CECW-ET. 

The  work  was  performed  by  the  Engineering  Processes  Branch  (CF-N)  of  the  Fa¬ 
cilities  Division  (CF),  Construction  Engineering  Research  Laboratory  (CERL). 
The  CERL  Principal  Investigator  was  E.  William  East.  Ms.  Jana  KeUy  was  the 
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such  commercial  products.  All  product  names  and  trademarks  cited  are  the  property  of  their  respective 
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unless  so  designated  by  other  authorized  documents. 
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1  Introduction 


Background 

The  U.S.  Army  Corps  of  Engineers  (USAGE)  manages  design  and  construction 
activities  for  Army,  Air  Force,  and  many  other  Federal  and  non-Federal  agen¬ 
cies.  Given  the  high  tximover  of  experienced  personnel  throughout  the  Archi¬ 
tect/Engineer/Contractor  (A/E/C)  commxmity,  the  capture,  evaluation,  and  use  of 
organizational  knowledge  such  as  lessons  learned,  success  stories,  and  good  work 
practices  are  essential  if  the  quality  of  Corps  products  is  to  continue  to  be  high. 

Past  experience  has  shown  that  proprietary,  stand-alone  systems  that  capture 
and  use  lessons  learned  are  too  expensive  to  maintain  over  time.  An  integrated 
approach  that  uses  commercially  available  software  is  needed.  The  intersection 
of  the  process  whereby  organizational  knowledge  can  be  captured  and  evaluated, 
and  the  process  of  design  and  Biddability,  Constructability,  and  Operability 
(BCO)  reviews  provides  one  of  the  best  points  at  which  to  develop  an  integrated 
method.  Turning  an  individual’s  unique  project  learning  into  corporate  knowl¬ 
edge  is  the  essential  core  of  the  effort  behind  Design  Review  and  Checking  Sys¬ 
tem  (DrChecks)  and  its  companion  Corporate  Lessons  Learned  (CLL). 

In  developing  this  capability,  issues  that  needed  to  be  addressed  included:  the 
requirement  to  match  the  type  of  review  conducted  with  the  nature  of  the  project 
under  design;  the  need  for  flexibility  in  defining  how  organizational  knowledge  is 
to  be  captured,  reviewed,  and  reused;  an  investigation  of  communication  tech¬ 
niques  that  would  be  as  useful  across  town  as  they  woiild  be  aroimd  the  globe; 
the  need  for  system  security;  the  high  cost  of  operating  and  maintaining  current 
automated  systems;  the  need  to  reduce  the  burden  imposed  on  users  who  are 
forced  to  constantly  upgrade  emd  re-leam  software  systems;  and  the  requirement 
to  provide  appropriate  reference  materials  to  personnel  as  needed. 

DrChecks/CLL  uses  a  secure.  Internet-based,  client-server  system  architectiore. 
All  users  access  the  program  using  free,  commercially  available  browser  soft¬ 
ware.  A  1-hour  demonstration  is  all  the  training  required.  Long-term  opera¬ 
tions  and  maintenance  costs  of  DrChecks/CLL  are  significantly  less  than  tradi¬ 
tional  software  because  DrChecks/CLL  is  composed  primarily  of  Commercial-Off- 
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the-Shelf  (COTS)  components.  There  are  no  per-user  fees  or  distribution 
charges. 

DrChecks/CLL  (hereafter  referred  to  as  DrChecks)  has  six  different  types  of  us¬ 
ers:  project  managers,  reviewers,  customers,  designers,  lessons-leamed  points  of 
contact  (POCs),  and  administrators.  Project  managers  create  review  phases  for 
each  project.  Reviewers  and  customers  conduct  design  reviews  and  submit  po¬ 
tential  lessons  learned.  The  designer  evaluates  review  comments  that  then  be¬ 
come  part  of  revised  plans  and  specifications.  Discipline-specific  lessons-leamed 
POCs  determine  if  a  pending  item  has  a  real  impact  on  operations,  is  factually  or 
technically  correct,  and  has  application  to  a  specific  process  or  component. 
Administrators  are  able  to  customize  the  DrChecks  program,  system  title,  search 
and  indexing  pick  lists,  and  many  other  featxires,  allowing  the  system  to  be  cus¬ 
tomized  for  any  site  by  someone  with  no  computer  programming  knowledge. 

The  user-specific  interface  of  DrChecks  allows  each  user  to  see  only  those  func¬ 
tions  and  information  appropriate  for  the  job  at  hand.  A  complete  history  of 
every  comment  and  designer  evaluation  is  provided  with  names,  telephone  num¬ 
bers,  and  email  addresses  so  that  users  can  easily  identify  and  follow-up  on  criti¬ 
cal  issues.  With  DrChecks,  users  can  spend  more  time  doing  their  jobs  and  less 
time  learning  software.  One  manager  even  joked,  “DrChecks  is  too  successful. 
Designers  and  reviewers  are  actually  talking  with  one  another.” 

Recognized  as  “Best  of  Breed”  by  a  1998  U.S.  Army  Corps  of  Engineers  (USACE) 
Headquarters  Lessons  Learned  task  force,  DrChecks  was  approved  for  opera¬ 
tional  testing  by  the  USACE  Board  of  Directors  and  designated  an  official 
USACE  Automated  Information  System  (AIS)  in  May  1998.  DrChecks  was  rec- 
ogmzed  by  the  Office  of  the  Secretary  of  Defense,  Quality  Management  as  a 
“Quality  Management  Best  Practice”  in  1999,  and  is  now  used  throughout 
USACE  and  the  Department  of  State’s  Office  of  Foreign  Building  Operations.  In 
May  2001,  Headquarters  USACE  mandated  the  use  of  DrChecks  throughout  the 
Corps  in  Fiscal  Year  (FY)  02. 

Due  to  the  flexibility  of  DrChecks,  offices,  large  or  small,  can  use  this  system. 
This  flexibihty  is  available  due  to  the  common  business  model  used  within 
DrChecks.  So  that  offices  of  all  sizes  can  use  DrChecks,  the  personal  settings 
can  be  customized.  The  overall  site  can  be  changed  to  include  the  office’s  name, 
a  welcome  message,  and  an  information  page  footer.  An  office  can  also  change 
codes  within  the  program  to  meet  its  needs.  These,  codes  are  disciplines,  project 
category  codes,  customer  codes,  location  codes,  and  document  types. 


Objectives 


DrChecks  has  four  objectives: 

1.  Improve  project  quality  —  Project  quality  is  improved  by  teams  being  allowed  to 
identify  issues  before  a  project  milestone  is  missed.  Past  comments  and  lessons 
are  kept  in  the  database  and  can  be  applied  by  reviewers  when  reviewing  a 
comment  or  lesson.  The  program  also  uses  a  standardized  process  that  helps  the 
customers  and  designers  to  easily  complete  their  reviews  for  a  project. 

2.  Reduce  construction  change  orders  —  DrChecks  provides  a  reliable  way  for  users 
to  communicate  with  others.  This  communication  increase  allows  users  to  inform 
others  of  problems  immediately  before  decisions  are  made.  In  turn,  the  number 
of  construction  change  orders  is  reduced. 

3.  Make  small  improvements  in  design  that  equal  a  large  life-cycle  return  —  When 
a  change  is  made  in  the  design,  the  whole  project  is  affected.  DrChecks  will  allow 
users  to  track  those  changes  and  make  quick  decisions  about  the  affected  project. 

4.  Improve  satisfaction  and  usefulness  of  the  facility  —  DrChecks  has  improved  sat¬ 
isfaction  and  usefulness  becaTose  it  is  easy  to  use.  Users  can  enter  comments  ei¬ 
ther  by  file  or  directly  on  the  site,  and  designers  can  review  comments  submitted. 
Users  can  also  find  the  status  of  the  site  that  includes  comment  summaiy 
information. 


Approach 

DrChecks  is  the  latest  in  a  series  of  products  developed  by  the  Engineer  Re¬ 
search  and  Development  Center’s  (ERDC’s)  Construction  Engineering  Research 
Laboratory  (CERL)  to  enhance  design  quality.  The  detailed  requirements  for 
DrChecks  were  developed  by  the  Design  Review  Tools  Steering  Committee  in  FY 
96  and  FY  97.  The  committee  includes  people  from  across  USACE  who  conduct 
or  manage  design  reviews  amd  those  people  who  develop  design  review  products 
and  set  regional  or  national  USACE  policy  regarding  design  reviews.  Users  firom 
within  and  outside  USACE  tested  DrChecks  in  FY  97.  Based  on  those  tests,  the 
system  revisions  were  implemented. 

The  World  Wide  Web  (WWW)  provides  the  communications  backbone  of 
DrChecks,  which  users  access  with  commercially  developed,  free  web  browser 
software.  Project  participants  without  a  permanent  web  connection  can  use 
commercial  services  for  under  $20  per  month.  The  hardware  and  software  to  op¬ 
erate  a  local  DrChecks  server  are  also  very  inexpensive  commercial  products. 
These  products  are  either  of  the  commercial-grade  web  server  systems  from 
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Microsoft®  and  Netscape'^;  the  Cold  Fusion®  web-database  query  software;  and 
the  Microsoft®  Access™  database.  The  total  cost  of  the  DrChecks  system  for 
most  offices  will  be  under  $600.  The  use  of  such  simple  and  inexpensive  com¬ 
mercial  software  also  means  that  personnel  with  limited  software  engineering 
knowledge  can  make  local  modifications  to  the  system  as  needed. 

DrChecks  is  a  cost-effective,  useful  way  to  capture,  manage,  and  use  corporate 
knowledge  in  the  context  of  a  fiilly  functional  design  review  tool.  Considering 
that  current  unrealized  costs  from  a  simple  design  review  may  reach  5  percent  of 
the  overall  construction  budget,  the  application  of  online  organizational  experi¬ 
ence  should  double  those  customer  savings.  Customer  satisfaction  should  also  • 

increase  as  the  criteria  used  by  various  customers  are  documented  in  success 
stories  and  lessons  learned.  An  even  more  important  aspect  of  DrChecks  is  that 
the  system  can  bring  project  stakeholders  together  to  produce  the  best  possible 
design  given  the  variety  of  constraints  that  make  each  project  unique.  Finally, 
the  overall  cost  of  the  design  review  features  of  DrChecks  could  be  significantly 
lower  than  the  cost  of  currently  used  methods  and  technology. 


Mode  of  Technology  Transfer 

Potential  users  typically  review  and/or  utilize  the  system  on  a  trial  basis  before 
making  a  decision  to  adopt  DrChecks  organization-wide.  The  General  Services 
Administration  (GSA)  has  purchased  one  site  license  for  the  system  and  is  cur¬ 
rently  determining  whether  to  adopt  it  throughout  all  11  of  its  regions.  Naval 
Facilities  Engineering  Command  (NAVFAC)  on  the  other  hand  reviewed  the  sys¬ 
tem  and  decided  to  adopt  it  without  a  test  period.  The  Federal  Aviation  Admini¬ 
stration  (FAA)  is  evaluating  DrChecks  as  a  potential  Govemment-Off-the-Shelf 
(GOTS)  software  service  provided  by  CERL.  DrChecks  is  in  use  at  one-third  of  # 

the  Corps  Districts  and  is  available  for  commercial  use.  Since  the  Corps  has 
mandated  the  use  of  DrChecks  by  all  Districts  in  FY  02,  the  economies  of  scale 
will  reduce  the  effective  site-license  costs  by  one-third. 

Currently,  CERL  is  operating  DrChecks  project  sites  for  a  large  number  of  Dis¬ 
tricts  in  the  Continental  United  States  (CONUS)  and  the  Europe  District.  CERL 
also  assists  the  Department  of  State  and  three  Districts  (Honolulu,  Japan,  and 
Korea)  in  the  Pacific  Ocean  Division  (CEPOD)  that  operate  their  own  DrChecks 
servers.  CERL  support  for  DrChecks  sites  includes  web  server  management, 
daily  and  weekly  server  backups,  toll-free  telephone  support,  and  a  technical 
support  bulletin  board  for  a  per-prqject  fee.  Delivery  of  DrChecks  to  individual 
offices  can  be  arranged  depending  on  the  specific  requirements  for  a  given  office. 
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Training  and  presentation  materials  are  provided  online.  This  report  is  accessi¬ 
ble  through  the  WWW  at  http://www.cecer.army.mil. 
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2  Implementation  Strategy 

Initial  Implementation 

Initial  fielding  of  DrChecks  was  on  a  voluntary  annual  license  purchase  basis. 
Beginning  in  FY  98  with  4  Corps  of  Engineer  Districts,  the  number  of  subscrib¬ 
ing  users  has  steadily  grown  to  9  in  FY  99, 13  in  FY  00,  and  16  in  FY  01.  During 
this  period,  other  agencies  such  as  the  Department  of  State  Foreign  Building  Of¬ 
fice  and  GSA  began  to  use  DrChecks. 


Enterprise  Implementation 

General  Services  Administration 

GSA  has  indicated  an  interest  in  standardizing  on  the  use  of  DrChecks  for  all  of 
their  11  regions.  Initial  testing  must  be  completed  prior  to  an  organization-Avide 
implementation  decision.  The  GSA  POC  has  indicated  a  desire  to  include  user 
training  in  their  implementation  at  all  regions. 

Naval  Facilities  Engineering  Command 

While  NAVFAC  has  agreed  to  implement  DrChecks  throughout  the  organization, 
initially  they  will  purchase  licenses  for  their  four  major  Engineering  Field  Divi¬ 
sions  (EFDs).  PHiture  additional  licenses  would  be  required  for  DrChecks  to  sup¬ 
port  each  orgamzation  that  actually  runs  (controls)  the  design  review  process. 

U.S.  Army  Corps  of  Engineers 

Successful  completion  of  field  testing  of  DrChecks  with  the  CLL  Module  in  Fall 

1999  offered  the  possibility  for  integrating  corporate  lessons  learned  capabilities 
across  a  number  of  other  key  USACE  business  processes.  Diuing  the  13-15  Jime 

2000  Directors  of  Programs  Management /Engineering  Technical  Services 
(DPM/DETS)  Laydown,  a  decision  was  made  to  adopt  DrChecks  as  the  Corps’ 
official  design  review,  lessons  learned,  and  feedback  system.  As  a  result  of  that 
meeting  DrChecks  was  chosen  to  supersede  the  Automated  Review  Management 
System  (ARMS)  as  the  required  repository  for  collating  and  transmitting  project 
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review  comments.  Consistent  with  this  policy,  Engineer  Regulation  (ER)  1110-1- 
8154  that  mandated  use  of  ARMS  was  rescinded  by  Engineer  Circular  (EC)  25-1- 
292  dated  4  October  2000.  A  new  ER  1110-1-8159  issued  in  May  2001  reflected 
this  decision. 

Along  with  the  decision  to  standardize  on  DrChecks,  enterprise-wide  funding 
will  be  provided  for  aU  Districts.  A  phased-in  approach  will  be  followed  so  exist¬ 
ing  projects  can  be  completed  without  converting  to  DrChecks  mid-stream.  Full 
implementation  is  expected  by  the  FY  04  timeframe. 


3  Process  Information 


Overall  Processes 

Users  will  find  many  options  in  DrChecks  to  help  them  communicate  with  co- 
workers  while  keeping  accurate  records  of  activities  that  are  being  worked  on  or 
completed  for  a  job.  Options  are  divided  according  to  access  rights  of  each  user 
and  by  type  of  activities  to  be  performed.  A  brief  description  of  these  processes 
are  listed  below  and  categorized  as  they  are  in  DrChecks.  Further  details  on 
how  these  processes  work  and  what  information  is  collected  in  each  process  are 
discussed  later  in  this  chapter. 

Account  Info 


The  “New  User”  screen  shows  the  registration  form  for  users  new  to  DrChecks. 
A  user  must  have  the  office  password  to  which  they  are  associated.  Once  regis¬ 
tered,  the  user  receives  a  personal  password.  The  “Update  User”  screen  provides 
a  form  to  change  user  information  if  needed.  Information  given  during  registra¬ 
tion  is  automatically  pre-filled.  The  “Reset  User”  screen  allows  a  user  to  reset 
the  user  settings  for  DrChecks  to  their  own  settings.  The  password  that  should 
be  used  here  is  the  personal  password  that  was  assigned  after  initial  registra¬ 
tion. 

Projects 

Activity  details  are  stored  in  a  project.  When  created  in  the  “New  Project” 
screen,  a  project  should  contain  information  concerning  the  type  of  project  and 
its  expected  dm-ation.  Project  managers  use  the  “Update  Project”  screen  to  edit 
project  details  such  as  calendar  dates  and  project  categories.  A  project  manager 
needs  to  use  “Access  Rights”  to  assign  individuals  or  groups  to  a  project.  Access 
rights  are  required  k  on  a  project  as  one  unit  instead  of  assigning  individual  ac¬ 
cess  rights  to  each  person.  Projects  contain  reviews  that  represent  phases  in  a 
project.  When  a  phase  is  complete  and  no  longer  active,  a  project  manager  can 
xise  the  “Archive  Project”  screen  to  archive  the  review,  making  it  read  only.  A 
project  manager  should  use  the  “Delete  Project”  process  if  the  project  is  complete 
and  no  longer  needs  to  be  accessed.  It  is  advised,  however,  that  the  project  be 
archived  before  deletion  because  the  deletion  is  not  reversible. 
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Reviews 

A  review  represents,  a  phase  in  a  project.  A  review  can  be  created  in  “New/ 
Update”  by  identifying  the  name  and  expected  duration.  If  a  review  is  already 
created,  a  user  can  edit  review  details  in  this  process  as  well.  A  review  contains 
comments  from  users  while  communicating  about  a  project.  A  user  can  use  “Im¬ 
port  Comments”  to  import  a  comment  into  a  review  when  the  comment  is  located 
in  a  different  file.  A  review  can  also  contain  comments  that  are  entered  by  us¬ 
ers.  If  a  user  in  DrChecks  would  like  to  enter  a  comment,  the  “Add  Comments” 
process  may  be  used.  Once  a  comment  is  added,  it  is  left  pending  imtil  a  de¬ 
signer  reviews  it.  Pending  comments  are  the  only  comments  with  fields  that  can 
still  be  edited  in  the  “Edit  Comment”  process  (if  needed).  A  reviewer  creates  the 
comment  and  the  designer  reads  the  comment  and  replies  in  the  “Designer  Chk” 
process.  The  designer  should  specify  concurrence  or  no  concurrence  and  com¬ 
ment  on  why.  A  reviewer  can  use  the  “Designer  Import”  process  to  reply  to  pend¬ 
ing  comments  when  the  reply  is  located  in  a  different  file.  In  “Backcheck,”  if  a 
comment  has  been  reviewed,  a  designer  may  close  the  comment  or  leave  it  open 
for  further  review. 

Lessons 

The  “New  Lesson”  form  is  for  reporting  a  problem  or  an  idea  that  needs  to  be 
looked  into  further.  A  lesson  is  submitted  to  a  POC  who  uses  “POC  Evaluate”  to 
evaluate  the  lesson  and  determine  if  it  is  valuable.  A  pending  lesson  may  be  up¬ 
dated  in  the  “Review/Update  Lesson”  screen.  If  a  lesson  is  approved  or  disap¬ 
proved,  a  user  may  review  it.  If  disapproved,  a  user  may  also  resubmit  the  les¬ 
son.  Only  certain  people  are  POCs  and  allowed  to  review  a  lesson.  If  a  user 
wants  to  assign  POC  rights  to  another,  they  may  do  so  in  the  “Lesson  Access 
Rights”  process. 

Find 

The  “Quick  Find  Comments”  process  allows  a  user  to  search  for  a  comment  in 
the  database  by  specifying  a  keyword(s)  or  by  searching  all  comments.  The  “Ad¬ 
vanced  Find  Comments”  process  allows  a  user  to  narrow  a  search  for  a  comment 
by  providing  various  fields  to  search.  “Find  Lessons”  allows  a  user  to  identify 
search  criteria  to  find  a  specific  lesson.  After  a  review  has  been  archived,  a  user 
will  be  able  to  view  the  archive  address  and  have  the  opportunity  to  see  the  ar¬ 
chive  in  the  “View  Archive”  process.  The  “Site  Status”  screen  shows  summaries 
of  activities  on  a  site  or  reports  on  category  information. 
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Admin 

The  “Update  Cat  Codes”  process  allows  a  user  to  either  add  or  update  category 
code  information.  The  “Update  Customers”  process  allows  a  user  to  either  add  or 
update  customer  information.  Customer  information  represents  the  agency  an 
office  is  listed  under.  The  “Update  Disciplines”  process  allows  a  user  to  either 
add  or  update  discipline  information.  The  “Update  Doc  Types”  process  allows  a 
user  to  either  add  or  update  document  type  information.  The  “Delete  Lessons” 
process  allows  a  user  to  search  for  and  delete  a  specific  lesson  by  identifying  cri¬ 
teria.  Deleting  a  lesson  is  not  reversible.  The  “Update  Locations”  process  allows  . 
a  user  to  either  add  or  update  location  information.  The  “Update  Offices”  proc¬ 
ess  allows  a  user  to  either  add  or  update  office  information.  The  “Update  Users” 
process  allows  a  user  to  either  add  or  update  user  information.  An  information 
list  for  each  employee  within  the  District  can  also  be  retrieved.  The  “Update 
Welcome”  process  allows  a  user  to  update  what  others  see  on  the  screen.  The 
screen  consists  of  the  header,  body,  and  footer,  which  are  all  required. 


Access  Rights 


Activities  in  DrChecks  are  categorized  by  the  type  of  users  who  use  them.  Access 
rights  allow  users  to  work  with  these  specific  activities.  The  grid  in  Table  1 
shows  access  rights  for  the  different  types  of  users.  The  X’  indicates  an  access 
right  that  is  given  to  a  user  classified  as  that  type.  If  access  has  not  been  as¬ 
signed,  the  user  receives  an  error  message.  A  user  can  be  more  than  one  type  of 
user  at  the  same  time.  He/she  may  be  a  reviewer,  designer,  and  manager  and 
have  all  of  the  access  rights  that  go  with  each  type.  Another  user  may  be  a  de¬ 
signer  only.  Table  1  shows  a  grid  that  represents  users  assigned  to  one  user  type 
only. 
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Process  Descriptions 
New  User 

This  section  explains  how  new  users 
enter  information  about  themselves 
and  their  offices.  It  is  not  possible 
to  execute  this  sequence  without  ac¬ 
cess  to  the  company  password,  so 
new  iisers  should  already  have  that 
password  when  starting.  Registered 
users  may  enter  other  users  into  the 
system  with  this  page.  Figure  1 
shows  the  process  steps. 

In  Part  1  (Figure  2)  a  user  will  need 
to  enter  items  such  as  first  and  last 
names,  email  address,  his/  her  of¬ 
fice,  and  the  discipline  he/  she  par¬ 
ticipates  in  the  most.  Part  2  shows 
all  information  about  that  user  in¬ 
cluding  the  office  address  and  phone 
munber.  Once  the  user  has  con¬ 
firmed  the  information  is  correct. 
Part  3  will  show  the  permissions 
that  have  been  assigned  and  other 
rules  and  regulations  that  should  be 
observed  while  using  DrChecks. 


Figure  1.  Process  of  adding  a  new  user. 
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DrChecks/CLL  Demo 


Click  k  for  menu 

►  Help 
Account  Info 

New  User 
Update  User 

Reset  User 

►  Projects 

►  Reviews 

►  Lessons 
^  Find 

►  Admin 


iJser  Manual 

Tech  Support 
DrCheck'S  Project 


New  User,  Part  1  of  3  Hek 

Enter  user's  name  and  email.  The  office  pick  sets  default  address  data  so  you  don't  have  to  type  it  in.  The 
office  pick  also  sets  default  permissions.  The  office  password  must  match  the  selected  office.  Fields  with  an 
asterisk  are  required. 


First  Name 
Last  Name 


Your  Discipline 
Your  Office^ 


|yourname@offic8.orgaLnization.domain 
iRease  identiVvourdiscipli^^ 


CELRB-Buffalo  District 
-CELRB-Construction  Division 
-CELRB-Engineering  Division 
CENPP-Portland  District 
-CENPP-a  Group 
CENVW  Walla  Walla  District 
CEPOA-AIaska  District 

-  CEFOA-Fairbanks  Resident  Office 

-  CEPOA-Project  Management 


Office  Password  ; 


Title:  The  title  refers  to  a  person’s  marital  status,  education,  and  gender.  Men 
should  use  either  “Mr.”  or  “Dr.”  and  women  should  use  “Mrs.,”  “Ms.,”  or  “Dr.”  A 
married  woman  without  a  doctorate  degree  is  indicated  by  “Mrs.”  or  “Ms.”  “Mr.” 
or  “Ms.”  can  indicate  either  single  or  married  status  without  a  doctorate  degree. 
The  “Dr.”  title  should  be  used  only  for  a  person  who  has  obtained  a  doctorate  de¬ 
gree  regardless  of  marital  status  and  gender.  This  field  is  required. 

Name:  First  and  last  names  legally  given  to  a  user.  These  are  required  fields. 

Phone:  The  telephone  number  should  be  where  a  user  can  be  contacted  regard¬ 
ing  DrChecks  questions  or  concerns.  The  default  telephone  number  is  that  of  the 
user’s  office.  A  user  can  keep  this  number  or  change  it  to  a  direct  telephone 
number  that  can  also  be  reached  for  DrChecks  questions  or  concerns. 

Your  Discipline:  The  discipline  is  the  specialization  of  the  user.  A  dropdown 
list  of  disciplines  to  choose  from  is  provided.  If  there  is  not  a  distinct  discipline  a 
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user  is  involved  in  or  the  correct  discipline  is  not  on  the  list,  he/she  should  choose 
“Other”  for  the  discipline.  This  field  is  required. 

Your  Office:  A  person  completes  work  for  the  office  in  which  they  are  em¬ 
ployed.  Offices  are  divided  into  Divisions,  Districts,  or  offices  imder  Divisions  or 
Districts.  If  the  specific  office  is  not  listed,  he/she  should  contact  the  office  or 
Division  they  are  completing  work  for  to  find  out  the  correct  listing. 

Address:  The  address  consists  of  the  street,  post  office  box,  city,  state,  zip  code, 
and  mail  stop.  The  default  address  is  that  of  the  user’s  specified  office.  These 
address  fields  can  be  revised. 

FAX:  The  fax  number  is  where  a  copy  of  a  document  can  be  sent  electronically 
without  using  a  computer. 

Email:  Messages  may  be  sent  electronically  to  this  address  via  computer  work¬ 
stations.  This  address  will  be  used  to  mark  materials  a  user  submits  and  to  com¬ 
municate  with  other  users  while  using  DrChecks.  It  is  important  to  enter  the 
correct  email  address.  This  field  is  required. 
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Update  User 

User  information  can  be  updated  here  as  needed.  Data  listed  in  the  system  for 
the  individual  are  presented  and  may  be  edited  as  desired.  If  the  information  is 
incorrect,  another  user  may  be  registered  on  the  workstation.  In  this  case,  the 
user  will  first  need  to  go  to  the  “Reset  the  Usei^  section,  which  is  discussed  in  the 
next  section.  Figure  3  shows  the  process  steps.  User  information  on  “Update 
User”  Part  1  (Figure  4)  can  be  edited,  but  no  changes  will  be  made  until  the 
proper  password  is  entered  and  the  [Continue]  button  pressed. 


Figure  3.  Process  of  updating  a  user. 


j  j  http://vywy-buidefsnetofg/Acheck«/vefsion2yfnain.cfm?RESETSITE«CECER 


HOME 

Click  ^  for  menu 


DrChecks/CLL  Demo 


Update  User 

Change  ytju*  name,  address,  phone  xiumbet,  and  email  in  the  form  provided  belotv.  (Dptional  mailing 
address  infonnation  is  also  provided  Office  end  Password  may  only  be  changed  by  the  system 
adnunistrator. 


Tdc"':  [Ms 
First  Name*  [Test 
Last  Name*;  fuser 

Phone*:  pM5W555 


Fmail*-  (testus  ere  mail  (3emeiil.com 

Your  Discipline*:  i  Other 

Your  Office;  Resource  Center  Enterprises 
Office  Name:  | 

Street  |  ^ 

P.O.  BOX  I 

Mail  Stop:  |  — — 


Cit^  lUrbandZ 


Figure  4.  Update  User  Part  1. 
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Reset  User 

This  section  is  for  current  users  to 
reset  their  secxuity  key  and  simid- 
taneously  update  user  information 
stored  in  DrChecks  databases.  It  is 
not  possible  to  execute  this  sequence 
without  access  to  the  personal  pass¬ 
word.  Registered  users  may  enter 
other  users  into  the  system  with  this 
page.  Figure  5  shows  the  process 
steps. 

To  reset  the  user  information,  the 
name  of  the  user  and  the  user’s  per¬ 
sonal  password  shotdd  be  entered  in 
the  fields  in  Part  1  (Figure  6)  before 
proceeding  to  Part  2.  The  personal 
password  is  automatically  assigned 
to  a  user  when  his/her  account  is 
created.  To  clear  a  user  accotmt, 
click  on  the  [Clear  Accoimt]  button 
located  on  Part  1  of  “Reset  User.” 


Figure  5.  Process  of  resetting  a  user. 
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DrChecks/CLL  Demo 


Click  ^  for  menu 

►  Help 
Account  Info 

New  User 
Undate  User 

►  Projects 

►  Reviews 

►  Lessons 

►  Find 

k  Admin 


User  Manual 

Tech  Support 
DrC hecks  Proiect 


Reset  User,  Part  1  of  3  « 

Scroll  through  the  list  of  re  gisUred  users,  sorted  by  last  name.  Select  your  name.  Enter  your  personal 
password,  then  click 'Reset'. 


Pick  your  name:  I 


Arteaga  Mauro 
Bartels.  Jule 
Beard  William 
Bob.  Billy 
Bozada  Thomas 
Caldas.  Carlos 
CaJIan,  Kim 
Cardenas.  Ruben 
Camero.  Alicia 


Enter  your  password: 


T'CbntiBua'^ 


Clea'Act^nt'^; 


Figures.  Reset  User  Part  1. 


This  gOTcnuHCHt  site  is  maintained  at  the  Resottrce  Center  Enteroriseg. 


Comments  and  suggestions  to  Jeff  Moll  or  l-800-^!8-4357. 
Pick  another  DiChecks/CLL  Site.  Help 


In  Part  2  the  user  can  confirm  and/or  edit  the  fields.  After  account  data  are  en¬ 
tered,  the  defaiolt  permissions  for  the  company  are  assigned  to  the  user.  Based 
on  the  permissions  a  user  has  been  assigned,  each  activity'  a  user  is  allowed  to 
work  on  in  DrChecks  is  listed  in  Part  3. 


Title:  The  title  refers  to  a  person’s  marital  status,  education,  and  gender.  Men 
should  use  either  “Mr.”  or  “Dr.,”  and  women  shovild  use  “Mrs.,”  “Ms.,”  or  “Dr.”  A 
married  woman  without  a  doctorate  degree  is  indicated  by  “Mrs.”  or  “Ms.”  “Mr.” 
and  “Ms.”  indicate  either  single  or  married  status  without  a  doctorate  degree. 
The  “Dr.”  title  should  be  used  only  for  a  person  who  has  obtained  a  doctorate  de¬ 
gree  regardless  of  marital  status  and  gender.  This  field  is  required. 

Name:  First  and  last  names  legally  given  to  a  user.  These  fields  are  required. 

Phone:  The  telephone  number  should  be  where  a  user  can  be  contacted  regard¬ 
ing  DrChecks  questions  or  concerns.  The  default  telephone  number  is  that  of  the 
user’s  office.  A  user  can  keep  this  number  or  change  it  to  a  direct  telephone 
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number  that  can  also  be  reached  for  DrChecks  questions  or  concerns.  This  field 
is  required. 

Your  Discipline:  The  discipline  is  the  specialization  of  a  user.  A  dropdown  list 
of  disciplines  to  choose  from  is  provided.  If  there  is  not  a  distinct  discipline  a 
user  is  involved  in  or  the  correct  discipline  is  not  on  the  list,  he/she  should  choose 
“Other”  for  the  discipline.  This  field  is  required. 

Your  Office;  A  person  completes  work  for  the  office  in  which  they  are  em¬ 
ployed.  Offices  are  divided  into  Divisions,  Districts,  or  offices  under  Divisions  or 
Districts.  If  the  specific  office  is  not  listed,  he/she  should  contact  the  office  or  Di¬ 
vision  they  are  completing  work  for  to  find  out  the  correct  listing. 

Address:  The  address  consists  of  the  street,  post  office  box,  city,  state,  zip  code, 
and  mail  stop.  The  default  address  is  that  of  the  user’s  specified  office.  These 
address  fields  can  be  revised. 

FAX:  The  fax  nximber  is  where  a  copy  of  a  document  can  be  sent  electronically 
without  using  a  computer. 

Messages  may  be  sent  electronically  to  this  address  via  computer  work¬ 
stations.  This  address  will  he  used  to  mark  materials  a  iiser  submits  and  to  com¬ 
municate  with  other  users  while  using  DrChecks.  It  is  important  to  enter  the 
correct  email  address.  This  field  is  required. 
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New  Project 

This  section  of  DrChecks  is  used  to 
create  a  new  project.  A  project  con¬ 
tains  reviews  and  comments  about 
the  imcompleted  task.  The  person 
who  creates  the  project  will  be  the 
project  manager  who  can  assign  ac¬ 
cess  rights  for  the  project  to  other 
individuals.  Figure  7  shows  the 
process  steps.  In  Part  1  (Figure  8), 
the  category  code,  customer  cate¬ 
gory,  and  location  category  need  to 
be  chosen  from  the  options  listed  in 
the  boxes.  After  clicking  on  the 
[Continue]  button,  the  user  will  pro¬ 
ceed  to  Part  2  (Figure  9). 

In  Part  2  the  project  name  and  the 
start  and  end  dates  should  be  speci¬ 
fied.  Also  on  this  screen,  the  cate¬ 
gory  code,  customer  category,  and 
location  category  choices  made  in 
Part  1  need  to  be  “narrowed  down.” 
All  fields  must  be  filled  or  selected  in 
order  to  create  the  project.  After  a 
user  clicks  on  [Continue],  the  new 
project  is  in  the  listing  of  all  other 
projects  for  the  site. 


Figure  7.  Process  of  creating  a  project. 
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New  Project,  Part  1  of  3  ak  ^ 

Select  one  category  from  each  of  the  following  options.  These  categories  are  used  to  assist  users  to  find 
comments  and  lessons  learned  on  the  new  project  If  you  decide  to  make  a  diffwent  selection,  you  may  come  ; 
b  ack  to  this  page  and  pick  a  differ ent  c  ate  gory. 


Project  Category  Code: 


Civil  Works  Categoiy  Codes 
HTRW  Category  Codes 
Milrtory  Category  Codes 


Customer  Category:  I 


Army  Customers 
Federal  Government  Agencies 
Foreign  Governments 
Local  Customers 
Other  Military  Customers 


Location  Category:  ; 


Foreign  Country  Codes 
Local  Sites 
U.S.  State  Names 


Figures.  New  Project  Part  1. 
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►  Reviews 
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New  Project,  Part  2  of  3 

There  ere  three  categories  ofinfonBationto  enter,  project  description,  project  categories,  end 
assignments.  Project  description  and  category  infbimation  is  required. 


Project  Descr^tioo: 
Project  Name* 
Desiga  Start*: 
Design  End*:  f” 
Project  Categories: 


(e  g.  Ol-Jun-2001) 
(e.g.  01-Jun.2001) 


Cat  Code* 


01 00:  Air  3 

01 OOA;  Deep  Draw  Down  Wells 
01 00-Q;  Dredging 
01 00-C:  Dewatering 

01 OO-D:  Extract  Remove,  Excavate  And  Treatment 
01 00-E:  Extract  Remove,  Excavate  And  OfFSite  Disposal 
01 OO-F:  Regrade 
01 00-G:  Vegetate 

01 00-H:  T reatment  In  Place  i^| 

jcilent  Office  2 
IdEF  Customer 


Figure  9.  New  Project  Part  2. 
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Project  Category  Code:  The  project  category  code  will  show  what  the  project 
activities  involve.  The  code  can  be  one  of  three  types:  (1)  The  Civil  Works  cate¬ 
gory  code  shows  activities  not  broken  down  into  specific  facilities  or  tasks,  (2)  the 
HTRW  (Hazardous,  Toxic,  or  Radioactive  Waste  programs)  category  code  shows 
task-specific  activities  that  may  include  handling  dangerous  materials,  and  (3) 
military  codes  show  tasks  needed  for  a  specific  facihty.  This  field  is  required. 

Customer  Category  Code:  The  customer  category  code  will  show  to  whom  the 
project  pertains.  Army  customers  are  the  branches  of  the  U.S.  Army.  Federal 
Government  Agencies  are  customers  that  work  for  the  U.S.  Government  and  are 
not  included  in  the  military.  Foreign  Governments  are  non-U.S.  governments 
doing  business  with  the  DrChecks  agency.  Local  customers  are  not  U.S.  Gov¬ 
ernment  or  military  specific.  Other  Mihtary  Customers  are  the  branches  of  the 
military  not  included  imder  the  Army  Customers.  This  field  is  reqiiired. 

Location  Category  Code:  The  location  category  code  shows  where  the  project 
is  located.  Foreign  Country  Codes  shows  the  names  of  various  foreign  countries. 
Local  Sites  shows  nearby  locations.  U.S.  State  Names  lists  edl  U.S.  states.  This 
field  is  required. 

Project  Name:  The  project  name  is  the  standard  project  reference  name.  The 
name  should  be  meaningful  and  typed  in  correctly  because  it  will  be  shown  on 
various  reports.  It  is  useful  to  include  one  keyword  that  allows  unique  identifi¬ 
cation  for  searching.  This  field  is  required. 

Design  Calendar:  The  design  calendar  is  for  the  “Design  Start”  and  “Design 
End”  dates  for  a  project.  The  design  start  date  should  be  greater  than  the  design 
end  date.  Dates  need  to  be  entered  in  the  dd-Mmm-yy  format  (e.g.,  lO-Oct-00). 
This  field  is  required. 

Cat  Code:  The  Cat  Code  is  a  more  specific  Civil  Works,  HTRW,  or  Military 
category  depending  on  what  Project  Category  Code  was  chosen.  If  the  category 
was  Civil  Works,  a  user  can  choose  an  activity  not  meant  for  specific  facilities  or 
tasks.  If  the  category  was  HTRW,  a  user  can  choose  a  task-specific  activity  that 
may  include  handling  dangerous  materials.  If  the  category  was  Military,  a  user 
can  choose  a  task  needed  for  a  specific  facility.  This  field  is  required. 

Customer:  The  customer  is  a  more  specific  customer  category  code.  It  refers  to 
the  group  or  organization  requesting  the  project.  Army  customers  are  the 
branches  of  the  U.S.  Army.  Federal  Government  Agencies  are  customers  that 
work  for  the  U.S.  Government  and  are  not  included  in  the  military.  Foreign 
Governments  are  non-U.S.  governments  doing  business  with  the  DrChecks 


agency.  Local  Customers  are  not  U.S.  Government  or  military  specific.  Other 
Military  Customers  are  the  br^ches  of  the  military  that  cannot  be  included  un¬ 
der  Army  Customers.  This  field  is  required. 

Location:  Location  targets  the  specific  area  where  the  project  is  taking  place. 
After  a  customer  has  chosen  a  larger  area  such  as  a  foreign  site,  a  local  site,  or  a 
U.S.  state,  a  site  within  that  larger  area  needs  to  be  chosen.  This  field  is  re¬ 
quired. 


Update  Project 

A  user  can  update  various  project 
specifications  in  “Update  Project.”  Pro¬ 
ject  managers  and  administrators  are 
the  only  users  with  access  to  update  a 
project.  Figure  10  shows  the  process 
steps. 

On  Part  1  of  the  “Update  Project” 
screen,  the  manager  selects  a  project  to 
update.  Clicking  on  the  project  name 
takes  the  user  to  Part  2  (Figure  11). 


Part  2  is  where  the  project  name, 
design  start  and  end,  cat  code,  loca¬ 
tion  code,  and  customer  code  may  be 
changed.  All  fields  are  required  and 
overall  project  categories  cannot  be 
changed,  because  these  categories 
are  carried  along  with  all  current 
and  future  comments  and  lessons 
learned.  After  making  the  necessary 
changes,  the  user  should  click  on  the 
[Update  Project]  button  to  finish  the 
update,  which  automatically  returns 
the  user  to  the  main  screen. 

Project  Name:  The  project  name  is 
the  standard  project  reference  name, 
which  should  have  been  given  when 
the  project  was  created  in  DrChecks. 
A  user  can  change  the  project  name 
in  “Update  Project.”  It  is  useful  to 
include  one  keyword  that  allows 
unique  identification  for  searching. 
This  field  is  required. 

Design  Calendar:  The  design  cal¬ 
endar  is  for  the  “Design  Start”  and 
“Design  End”  dates  for  a  project. 
The  design  start  date  should  be 
greater  than  the  design  end  date. 
Dates  need  to  be  entered  in  the  dd- 
Mmm-yy  format  (e.g.,  lO-Oct-00). 
This  field  is  required. 

Cat  Code:  The  Cat  Code  is  a  more 
specific  Civil  Works,  HTRW,  or  Mili¬ 
tary  category,  depending  on  what 
Project  Category  Code  was  chosen. 
If  the  category  was  Civil  Works,  a 
user  can  choose  an  activity  not 
meant  for  specific  facUities  or  tasks. 
If  the  category  was  HTRW,  a  user 
can  choose  a  task-specific  activity 
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Update  Project,  Part  2  of  2  m. 

Use  the  foimbcWto  change  the  project  data.  Note  that  overall  project  categories  cannot  be  changed  since 
these  categories  are  carried  along  with  all  currcnl/future  comments  and  lessons  learned 


Project  Descr^tioa- 

Project  Name*:  |Roof  Repair  Building  1106 
Design  Start*  |oi-Jun-00  (eg.  OlJun-2001) 


Design  Sid  :  |02-Jun“00 
Project  Categories: 


(e.g  OlJua-2001) 
(e.g  Ol-Jun-2001) 


Cat  Code*: 


720:  Unaccompanied  Personnel  Housing 
;  730:  Personnel  Support  and  Services 
740:  Moral,  Welfare  and  Reaeatioa  interio 
750:  Moral,  Welfare  and  Recreation.  Exterio 
760:  Museums  and  Memorials 
800:  Utilities  and  Ground  Improvements 
810:  Electric  Power 
820:  Heat  and  Refrigeration 
830:  Sewage  and  Waste 

US  Army  Material  Cmd 

US  Army  Military  Traffic  Mgmt  Cmd 

US  Army  Missile  Cmd 

US  Army  National  Guard  or  Bureau 

I  IS  Armv/ Smith  ^ 

^  i  i  i  i  i  i  w"' 


■  i 

'4 

Ml 

i 

M 

-  - 

§  4 

Figure  11.  Update  Project  Part  2. 


that  may  include  handling  dangerous  materials.  If  the  category  was  Military,  a 
tiser  can  choose  a  task  needed  for  a  specific  facility.  This  field  is  required. 

Customer:  The  Customer  is  a  more  specific  customer  category  code  that  refers 
to  the  group  or  organization  requesting  the  project.  Army  customers  are  the 
branches  of  the  U.S.  Army.  Federal  Government  Agencies  are  customers  that 
work  for  the  U.S.  Government  and  are  not  included  in  the  military.  Foreign 
Governments  are  non-U.S.  governments  doing  business  with  the  DrChecks 
agency.  Local  customers  are  not  U.S.  Government  or  military  specific.  Other 
Military  Customers  are  the  branches  of  the  military  not  included  under  Army 
Customers.  This  field  is  required. 

Location:  The  location  targets  the  specific  area  where  the  project  is  taking 
place.  After  a  customer  has  chosen  a  larger  area  such  as  a  foreign  site,  a  local 
site,  or  a  U.S.  state,  a  site  within  that  larger  area  needs  to  be  chosen.  This  field 
is  required. 
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Access  Rights 

For  a  riser  to  access  a  project,  he/she 
needs  to  have  access  rights.  The 
project  meinager  can  assign  these 
rights  by  going  into  “Access  Rights” 
and  selecting  the  project  and  the 
type  of  users  to  which  he/she  wishes 
to  assign  rights.  Figure  12  shows 
the  process  steps. 

Part  1  of  assigning  access  rights 
(Figure  13)  is  selecting  the  project 
and  the  type  of  users  to  which  he/she 
wishes  to  assign  rights.  Once  these 
two  selections  are  made,  the  user 
clicks  on  the  [Continue]  button. 

The  boxes  shown  in  Part  2  (Figure 
14)  contain  names  of  all  users  on 
that  site.  From  these  boxes,  the  user 
selects  names  to  assign  to  a  project 
and  then  clicks  on  the  [Add]  button. 
He/she  should  keep  in  mind  that 
each  category  of  user  is  going  to  be 
assigned  different  rights.  The  per¬ 
missions  granted  to  a  user  indicate 
which  activities  from  the  left-side 
menu  are  available  to  him/her.  If 
permission  has  not  been  given  to  a 
user  for  an  activity  and  it  is  selected, 
an  error  message  will  be  posted  to 
the  browser  indicating  an  attempt  to 
access  a  page  to  which  access  has 
not  been  given.  Access  to  specific 
projects  or  reviews  may  be  hmited 
by  the  user’s  office.  A  user  cannot 
access  a  project  until  rights  have 
been  assigned. 


Figure  12.  Process  of  assigning  access  rights. 
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Access  Rights,  Part  1  of  2 

Select  ipfpject  to  from  the  list  of  projects  below.  Men&gers  can  only  access  projects  assigned  to 

them.  Administrators  can  access  all  projects.  Use  the  search  f6hn  at  the  lop  of  the  page  to  find  selected  project 
(s).  You  may  view  up  to  20  projects  on  one  page.  Projects  ate  listed  in  a^habetical  order. 

Fmd  Project  j 


a  test  project  for  help  pages-do  not  del 
Barracks  352  Man  (test) 

BLR  Test  Project  1 

Newmark 

project  test  4- 

Roof  Repair  Building  1 1 06 
Standard  Comments 


U-;9f  Manual 

Tech  Stjuncut 
DnChecKs  Project 


Screeners 

Assignment 

Individuals 


Figure  13.  Access  Rights  Part  1. 
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Archive  Project 

Delete  Project 

►  Reviews 
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Access  Rights,  Part  2  of  2  suh 

Use  the  form  below  to  assign  permissions  for  the  selected  project  Hold  the  CTRL  key  and  to  make 

multiple  selections. 


CurrextPnjeci:  RMfRepsdrBnflling  1106 


Mr  Jule  Bartels 
Dr  Billy  Bob 
Mr  Thomas  Bozada 
Mr  Carlos  Caldas 
Ms  Alida  Camero 
Dr  Michael  Case 
Mr  RickDahnke 
Ms  Debra  Davis 
Mr  Agapito  Diaz 
Ms  Suzanne  Fallon 


Mr  Mauro  Arteaga  j 
Mr  Jule  Bartels  J 
Dr  Billy  Bob 
Mr  Thomas  Bozada  ' 
Mr  Carlos  Caldas  " 
Dr  Michael  Case  i 
Mr  RickDahnke 


Mr  Mauro  Arteaga 
Mr  William  Beard 
Mr  Kim  Callan 
Mr  Ruben  Cardenas 
Mr  James  Cauthom  ^ 
Mr  test  customer 
Mr  Robert  Dains  ^ 

Mr  David  Eakin  ^ 

Mr  Bill  East 

Mr  A1  Gilson  f 


Mr  Wiliam  Beard 
Mr  Kim  Callan 
Mr  James  Cauthom 
Mr  test  customer 
Mr  Robert  Dains 
Mr  Sample  Designer 
Mr  Typical  Designer 


Figure  14.  Access  Rights  Part  2. 


ERDC/CERL  SR-01-20 


35 


Project  Name:  The  project  name  is  how  the  project  is  referenced.  In  “Access 
Rights”  the  project  name  is  the  project  a  user  can  access  if  the  correct  rights  are 
assigned.  This  field  is  required. 

Assignment  Types:  When  a  user  wishes  to  assign  access  rights,  he/she  must 
decide  to  assign  an  individual  or  a  group  of  people.  For  example,  if  “Offices” 
were  selected,  he/she  would  be  able  to  assign  a  whole  office  and  not  just  an  indi¬ 
vidual  fi"om  that  office.  If  he/she  chooses  to  assign  individuals  they  may  do  so. 
This  field  is  required. 

Unassigned  Users:  A  person  is  placed  into  the  defavdt  vmassigned  box  imtil 
he/she  has  been  given  certain  access  rights.  Each  box  of  unassigned  users  are 
teams  or  individuals  that  meet  the  criteria  of  the  assignment  type  chosen.  These 
individuals  or  groups  are  also  divided  into  reviewers,  designers,  managers,  and 
customers. 

Assigned  Users:  An  assigned  user  has  access  rights  to  a  certain  project.  Each 
type  for  which  a  user’s  name  appears  in  the  assigned  box  will  give  access  rights 
in  that  division.  For  example,  if  a  user  is  assigned  as  a  reviewer  and  designer, 
the  only  access  rights  the  user  has  are  reviewer  and  designer  rights. 

Project  Teams 

A  project  team  is  a  group  of  individuals  assigned  access  rights  as  a  team.  The 
names  of  these  individuals  will  be  listed  when  it  is  time  to  assign  individual  ac¬ 
cess  rights  for  a  project.  Figure  15  shows  the  process  steps.  To  create  a  team, 
the  user  needs  to  choose  how  to  organize  the  team  in  Part  1  (Figure  16).  The 
user  can  organize  by  location,  customer  type,  category  code,  or  standard  screen- 
ers.  After  each  selection  is  made,  the  user  needs  to  click  on  [Continue]  to  pro¬ 
ceed  to  Part  2. 

Once  the  team  organization  has  been  chosen,  the  type  of  location,  customer,  or 
category  code  depending  on  what  was  chosen  in  Part  1  should  be  selected  in  Part 
2.  If  “Standard  Screener”  was  chosen  in  Part  1,  "Cxirrent  Screeners”  should  be 
chosen  fi'om  the  “All  Reviewers”  box.  Once  the  team  is  created,  the  user  clicks  on 
the  [Assign]  button  to  move  to  Part  3. 
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►  Help 

^  Account  Info 
▼  Projects 
New  Proiect 


Undate  Project 


Access  Riahts 


Proiect  Teams 


Archive  Project 


Delete  Proiect 


►  Reviews 


iS7> 
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Figure  16.  Project  Teams  Part  1. 


If  location,  customer,  or  category  code  was  chosen  in  Part  2,  the  user  will  need  to 
make  those  selections  more  specific  in  Part  3.  If  grouping  teams  by  selecting 
screeners,  one  standard  screener  must  be  chosen  in  Part  3  from  the  hst  of  as¬ 
signed  screeners  created  in  Part  2.  Reviewers  must  be  chosen  for  the  selected 
screener  by  holding  down  the  Ctrl  key  while  pointing  the  ctirsor  and  clicking  on 
each  name  to  be  assigned.  This  allows  a  user  to  select  multiple  users  not  in  con¬ 
secutive  order  in  the  list.  To  save  the  hst,  click  the  [Save  Now]  button.  In  Part  4 
(Figure  17),  boxes  on  the  left  contain  names  not  assigned  to  a  team.  Those  on 
the  right  are  already  on  the  team.  To  add  a  team  member,  the  user  should  high¬ 
light  that  person’s  name  and  chck  on  [Add].  The  name  should  then  appear  in  the 
box  on  the  right  side  of  the  screen.  To  delete  a  person  from  a  team,  the  user 
should  highlight  that  person’s  name  and  chck  on  the  [Del]  button.  Deleting 
moves  the  name  from  the  assigned  list  to  the  unassigned  list.  If  “Standard 
Screeners”  was  chosen  in  Part  1,  the  user  needs  to  choose  the  names  to  assign  in 
Part  2  by  chcking  on  the  names  and  clicking  on  the  [Add]  button  to  move  the 
name  to  the  righthand  box  where  the  assigned  screeners  are. 

Team  Type:  The  team  type  is  a  general  category  of  users  based  on  certain  cri¬ 
teria.  The  four  t3T)es  of  criteria  for  teams  are:  location,  customer,  category  code, 
and  screeners.  This  field  is  required. 

Location  Type:  If  a  user  chooses  the  team  type  based  on  location,  he/she  will 
need  to  choose  the  location  type  to  show  the  location  of  the  project.  Foreign 
Coimtry  Codes  will  show  the  names  of  various  foreign  countries.  Local  Sites  will 
show  nearby  locations.  U.S.  State  Names  wiU  list  names  of  all  U.S.  states.  This 
field  is  required. 
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Project  Teams,  Part  4  of  4  Bei  f] 

Use  the  fonn  below  to  assign  permissions  for  the  selected  project.  Hold  the  CTRL  key  and  click  to 
make  multiple  selections. 

Tott  are  current  creating  or  i^datbig  a  **!iH:atioii.based**  project  team  irhted  to  "  Cameioox". 


.K- 

Mr  Mauro  Arteaga 

•j  : 

(no  reviewers  assigne<5  / 

T- 

Mr  Jule  Bartels  H 

Mr  William  Beard 

■T 

Dr  Billy  Bob 

't  ■' 

Mr  Thomas  Bozada  V 

;Add> 

Mr  Carlos  Caidas  %  J 

S  'i 

Mr  Kim  Collan 

Mr  Ruben  Cardenas 

1 

Ms  Alicia  Carnero  * 

Dr  Michael  Case  jji 

e  ^ ' 
’ 

r^.^.  fMr  Mauro  Artei 

ifel: 


^  (no^desisners  assianecft 

*  »-*  "  sf  *  *  ^ ^  *  K  \  ^  ^ 


Figure  17.  Project  Teams  Part  4. 


Customer  Type:  If  the  user  chooses  the  team  type  based  on  customer,  he/she 
will  need  to  choose  the  customer  type  that  shows  to  whom  the  project  pertains. 
Army  customers  are  the  branches  of  the  U.S.  Army.  Non-Army  Military  Cus¬ 
tomers  are  the  branches  of  the  military  not  included  under  Army  Customers. 
Other  Government  Agencies  are  customers  that  work  for  the  U.S.  Government 
and  are  not  included  in  the  military.  Foreign  Governments  are  non-U.S.  gov¬ 
ernments  doing  business  with  the  DrChecks  agency.  Other  customers  are  not 
U.S.  Government  or  mihtary  specific.  This  field  is  required. 

Category  Code  Type:  If  the  user  chooses  the  team  type  based  on  Category 
Code,  he/she  needs  to  choose  the  category  code  type  that  shows  what  project  ac¬ 
tivities  are  involved.  Military  Construction  (MILCON)  codes  show  the  tasks 
needed  for  a  specific  facility.  The  Civil  Works  category  code  shows  activities  not 
broken  down  into  specific  facihties  or  tasks.  The  HTRW  category  code  shows 
task-specific  activities  that  may  include  handling  dangerous  materials.  Other 
codes  show  activities*  for  local  facilities.  This  field  is  required. 
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All  Reviewers:  If  the  user  chooses  to  create  the  team  by  standard  screeners, 
he/she  chooses  from  the  list  of  reviewers  to  create  screeners.  “All  Reviewers”  is  a 
list  of  users  that  have  access  rights  as  reviewers.  This  field  is  required. 

Current  Screeners:  Once  a  reviewer  is  picked  from  the  “All  Reviewers”  list, 
the  reviewer  then  becomes  a  ciirrent  screener.  A  screener  looks  at  comments  be¬ 
fore  they  are  sent  to  a  designer.  This  field  is  required. 

Location:  Location  targets  the  specific  area  where  the  project  is  taking  place. 
After  a  customer  chooses  a  larger  area  such  as  a  foreign  site,  a  local  site,  or  a 
U.S.  state,  a  site  within  that  larger  area  needs  to  be  chosen.  This  field  is  re¬ 
quired. 

Customer:  The  customer  is  a  more  specific  customer  category  code  that  refers 
to  the  group  or  organization  requesting  the  project.  Army  customers  are  the 
branches  of  the  U.S.  Army.  Federal  Gk)vemment  Agencies  are  customers  that 
work  for  the  U.S.  Government  and  are  not  included  in  the  mihtary.  Foreign 
Governments  are  non-U.S.  governments  doing  business  with  the  DrChecks 
agency.  Local  Customers  are  not  U.S.  Government  or  military  specific.  Other 
Military  Customers  are  the  branches  of  the  military  that  cannot  be  included  un¬ 
der  Army  Customers.  This  field  is  required. 

Cat  Code:  The  Cat  Code  is  a  more  specific  Civil  Works,  HTRW,  or  Military 
category  depending  on  what  Project  Category  Code  was  chosen.  If  the  category 
was  Civil  Works,  a  user  can  choose  an  activity  not  meant  for  specific  facilities  or 
tasks.  If  the  category  was  HTRW,  a  user  can  choose  a  task-specific  activity  that 
may  include  handling  dangerous  materials.  If  the  category  was  Military,  a  user 
can  choose  a  task  needed  for  a  specific  facility.  This  field  is  required. 

Standard  Screener:  The  standard  screener  should  be  chosen  out  of  the  list  of 
“Current  Screeners.”  Only  one  name  can  be  chosen;  however,  selected  screeners 
can  be  chosen  from  the  reviewer  hst.  This  field  is  required. 

Unassigned  Users:  A  person  is  placed  into  the  defavilt  unassigned  box  until 
he/she  has  been  given  certain  access  rights.  Each  box  of  unassigned  users  are 
teams  or  individuals  who  meet  the  criteria  of  the  assignment  type  chosen.  Also, 
these  individuals  or  groups  are  divided  into  reviewers,  designers,  managers,  and 
customers.  This  field  is  required. 

Assigned  Users:  An  assigned  user  has  access  rights  to  a  certain  project.  Each 
time  a  user’s  name  appears  in  the  assigned  box  gives  access  rights  in  that  divi- 
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sion.  For  example,  if  a  user  is  assigned  as  a  reviewer  and  designer,  the  only  ac¬ 
cess  rights  the  user  has  are  reviewer  and  designer  rights.  This  field  is  required. 

Archive  Project 


To  keep  a  copy  of  the  review  in  an¬ 
other  place,  a  user  may  choose  to 
archive  the  project.  This  does  not 
mean  the  review  will  no  longer  be 
accessible  or  will  be  deleted,  but 
rather  the  review  wiU  be  copied  to 
another  location  and  formatted  as  a 
Hypertext  Markup  Language 
(HTML)  document.  The  review  wiU 
still  be  there  to  access.  Figure  18 
shows  the  process  steps. 

To  archive  a  review,  a  user  first 
needs  to  select  the  project  containing 
the  comment  review.  This  is  done  in 
“Archive  Project”  Part  1.  The  review 
to  archive  needs  to  be  specified  in 
Part  2  (Figure  19).  Only  one  review 
can  be  chosen  at  a  time,  but  many 
reviews  from  the  same  project  can  be 
archived.  To  archive  this  review,  the 
user  clicks  the  [Archive  Now]  button. 

In  Part  3,  the  discipline,  count  of  ar¬ 
chives  for  review,  and  the  location  of 
the  archive  is  displayed.  To  view  the 
archive,  the  address  shown  in  blue 
should  be  selected.  Once  it  is  se¬ 
lected,  the  locations  of  the  project 
archive  directory  and  the  review  ar¬ 
chive  directory  are  displayed. 

Project  Name:  The  project  name  is 
the  standard  project  reference  nsime. 
In  “Archive  Project,”  the  project 
name  contains  reviews  to  archive. 
This  field  is  required. 
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Review  Phase:  A  review  is  a  representation  of  the  project  stage.  To  archive  a 
project,  the  user  needs  to  select  the  name  of  the  review  he/she  wishes  to  copy. 
This  field  is  required. 
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Figure  19.  Archive  Project  Part  2. 


Delete  Project 


A  xiser  may  need  or  want  to  delete  a  project  in  DrChecks.  This  simple  process  is 
for  managers  and  administrators  only  and  takes  just  two  steps  to  do.  Keep  in 
mind  that  the  delete  operation  cannot  be  undone.  Figure  20  shows  the  process 
steps.  To  delete  a  project,  it  needs  to  be  selected  from  the  list  of  projects  in  Part  1. 

In  Part  2  (Figure  21),  DrChecks  warns  that  not  only  will  the  selected  project  be 
deleted,  but  all  items  associated  with  it  will  be  deleted  as  well.  If  the  user  de¬ 
cides  to  delete  it  anyway,  the  [Delete,  Now!]  button  should  be  clicked;  otherwise, 
the  \iser  should  click  on  [Cancel]  to  move  back  to  Part  1  of  “Delete  Project.” 

Project  Name:  The  project  name  is  the  standard  project  reference  name.  In 
“Delete  Project,”  the  project  is  the  one  the  user  will  be  deleting.  When  a  project 
is  deleted,  only  the  archive  remains.  This  field  is  required. 


ERDC/CERL  SR-01-20 


Figure  21.  Delete  Project  Part  2. 
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Add/Update  Reviews 


Reviews  are  where  collections  of  comments  about  a  project  are  stored.  After  a 
project  is  created,  reviews  can  be  added.  To  update  a  review,  a  user  can  follow 
the  same  directions  for  adding  a  review.  Figure  22  shows  the  process  steps. 


Provide 

error 

message 


Figure  22.  Process  of  adding/updating  a  review. 
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In  Part  1  of  “Add/Update  Reviews,”  the  project  for  which  to  add  or  edit  a  review 
needs  to  be  specified  by  clicking  on  the  name  of  the  project.  Once  the  project 
name  has  been  chosen,  three  required  data  elements  need  to  be  collected  in  Part 
2  if  adding  a  review  or  displayed  if  editing  a  review.  These  elements  include  the 
review  name  and  the  start  and  end  dates  for  the  review.  After  these  three  are 
filled  in,  the  [Add  New]  button  shoiild  be  selected  to  add  a  review  (Figure  23). 
Otherwise,  the  [Update]  button  should  be  selected  (Figure  24). 

Project  Name:  The  project  name  is  the  standard  project  reference  name.  In 
“New/Update  Review”  the  project  name  is  the  project  where  the  review  is  located 
or  needs  to  be  added.  This  field  is  reqxiired. 

Reviews:  “Reviews”  contains  the  name  of  the  review  a  ^xser  wishes  to  update  or 
add.  Choose  a  descriptive  name  (e.g.,  90%  Complete).  This  field  is  required. 

Review  Date:  The  review  date  is  the  start  and  end  dates  of  the  review  and  is 
open  for  revision.  The  start  date  should  be  greater  than  the  end  date.  Dates 
need  to  be  entered  in  the  dd-Mmm-yy  format  (e.g.,  lO-Oct-00).  This  field  is  re¬ 
quired. 


Control  Number:  The  control  number  is  a  number  specifically  assigned  to  a 
review  for  internal  review  management  for  an  office.  This  field  is  optional. 
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Figure  23.  Add/Update  Review  Part  2- Add  New  Review. 
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Figure  24.  Add/Update  Review  Part  2  —  Update  Current  Review. 
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ServerURL:  The  ServerURL  is  the  address  where  all  reviews  can  be  found. 
This  field  is  not  yet  implemented. 

“Open”  Buttons:  The  three  different  “Open”  fields  are:  open  for  review,  open 
for  design,  and  open  for  backchecking.  When  one  of  these  options  is  selected 
“yes,”  the  review  can,  depending  on  the  selection,  have  comments  inserted  by  a 
reviewer  or  a  designer,  or  be  backchecked.  The  default  for  these  buttons  is  “yes.” 
This  field  is  required. 

Email  Update:  When  updating  the  review,  a  user  can  send  the  review  update 
to  all  reviewers,  customers,  or  designers  by  clicking  on  the  appropriate  check 
box.  A  box  is  provided  for  entering  email  addresses  and  additional  comments 
that  the  recipients  might  need  to  know  about  the  update. 
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Import  Comments 

If  a  user  wants  to  enter  comments 
located  in  a  different  file,  it  is  possi¬ 
ble  to  import  those  comments  to  any 
available  review  in  a  project.  To  see 
all  comments  for  a  review,  the  user 
clicks  the  [View  all  comments...] 
button.  Figure  25  shows  the  process 
steps. 

When  importing  comments,  the  pro¬ 
ject  to  import  to  must  be  selected  by 
clicking  on  the  project  name  in  Part 
1.  This  brings  up  Part  2  (Figure  26), 
where  the  review  into  which  the 
comment  is  to  be  imported  should  be 
selected.  Clicking  on  the  review 
name  brings  up  Part  3  (Figure  27). 
The  file  path  the  comment  is  located 
in  shoxild  be  specified  as  well  as  one 
reviewer  for  the  comment.  A  con¬ 
firmation  message  will  be  displayed 
in  Part  4  explaining  that  the  import 
was  successful. 

Project  Name:  “Import  Com¬ 

ments”  uses  the  project  name  to 
identify  the  location  of  the  review  to 
which  comments  are  to  be  imported. 
This  field  is  required. 

Review  Name:  To  import  a  com¬ 
ment  to  a  review,  a  user  selects  the 
name  of  the  review  that  he/she 
wishes  to  receive  the  comments. 
Comments  can  be  imported  to  any 
available  review.  This  field  is  re¬ 
quired. 

Comment  File:  When  importing  a 
comment,  which  means  it  is  stored 


in  a  different  file,  the  file  path  needs 
to  be  located  and  entered  into  the 
“Comment  File”  field.  The  [Browse] 
button  can  be  used  to  ease  the  loca¬ 
tion  process.  This  field  is  required. 
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Reviewer  Select:  Once  a  user  has  imported  a  comment,  he/she  needs  to  select 
a  reviewer  to  review  the  comment.  The  list  contains  names  of  all  assigned  re¬ 
viewers  for  the  project.  This  field  is  required. 
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Figure  26.  Import  Comments  Part  2. 
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Figure  27.  Import  Comments  Part  3. 
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Add  Comments 

To  communicate  to  coworkers  and 
other  users  about  a  project,  a  user 
must  add  a  comment  to  the  project. 
A  collection  of  these  comments  is 
grouped  into  a  review  that  repre¬ 
sents  a  stage  of  the  project.  Figure 
28  shows  the  process  steps. 

Before  adding  a  comment,  the  pro¬ 
ject  and  the  review  should  be  speci¬ 
fied.  The  project  name  can  be  se¬ 
lected  on  Part  1  of  “Add  Comments.” 


In  Part  2  the  user  selects  the  review 
to  receive  the  comment.  From  this 
page  it  is  also  possible  to  see  any 
pending  comments  or  unaccepted 
comments  in  the  “Your  Comments” 
column. 

After  the  review  is  selected,  the  “Add 
Comment”  form  is  displayed  in  Part 
3  (Figure  29).  The  fields  presented 
are:  document  type,  comment’s  dis¬ 
cipline,  spec  section,  drawing  sheet, 
drawing  detail,  code  reference, 
document  reference,  attachment, 
and  review  comment.  Reqviired 
fields  are  indicated  by  the  (*)  beside 
the  field  prompt.  When  all  required 
fields  and  desired  optional  fields  are 
complete,  clicking  on  the  “Add 
Comment”  button  will  complete  the 
addition  process. 

Once  the  comment  is  added  in  Part 
4,  the  user  will  then  be  returned  to 
Part  3  of  “Add  Comments”  in  order 
to  enter  any  additional  comments  for 
the  same  project. 

Project  Name:  The  project  name  is 
the  standard  project  reference  name. 
In  “Add  Comment”  the  project  con¬ 
tains  the  review  to  which  comments 
will  be  added.  This  field  is  required. 

Review  Name:  To  add  a  comment 
to  a  review,  the  user  needs  to  select 
the  name  of  the  review  where  the 
comment  shoidd  be  placed.  This 
field  is  required. 


Figure  28.  Process  of  adding  comments. 
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Figure  29.  Add  Comments  Part  3. 


Document  Type:  The  dociiment  type  is  the  part  of  the  project  that  the  added 
comment  affects.  For  example,  if  a  user  wanted  to  add  a  comment  to  say  “the 
specifications  were  incorrect,”  he/she  would  choose  “Specifications”  from  the 
dropdown  hst.  If  the  correct  docrunent  type  is  not  listed,  the  user  should  choose 
“Other.”  This  field  is  required. 

Comment’s  Discipline:  The  comment  discipline  defines  the  area  of  the  task. 
For  example,  if  the  user’s  comment  was  that  more  outlets  are  needed,  the  com¬ 
ment  discipline  would  be  “Electrical.”  If  a  certain  discipline  cannot  be  found  in 
the  hst,  the  user  needs  to  choose  “Other.”  It  is  reasonable  to  assume  one  user 
can  use  more  than  one  discipline  during  a  review.  This  field  is  required. 

Spec  Section:  When  a  user  needs  to  refer  to  the  project,  he/she  can  enter  a 
specification  reference.  The  specification  reference  helps  the  reviewer  identify 
the  individual  project  specification  of  the  comment. 

Drawing  Sheet:  The  “Drawing  Sheet”  field  is  a  reference  to  an  architectural 
drawing.  For  example,  if  a  user  wanted  to  show  all  outlets  in  a  bxoilding,  the 
drawing  sheet  could  reference  the  drawing  that  shows  the  outlets. 
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Drawing  Detail:  The  “Drawing  Detail”  field  is  a  reference  to  a  collection  of  ar¬ 
chitectural  drawings.  If  a  user  wants  a  reviewer  to  see  a  certain  sheet  in  a  col¬ 
lection,  he/she  can  reference  the  collection  containing  the  sheet. 

Code  Reference:  Federal  laws  or  regulations  may  be  referenced  in  the  “Code 
Reference”  field  if  necessary.  For  example,  if  a  user  wants  to  reference  the  law 
that  specifies  how  many  fire  extinguishers  are  required,  the  code  reference  would 
show  where  to  find  the  law. 

Document  Reference:  If  the  user  references  a  document  either  for  a  code  or 
specification  detail,  this  field  provides  a  place  to  store  the  reference. 

Attachment:  When  adding  a  comment,  the  user  can  use  this  field  to  add  sup¬ 
plemental  comments  or  pictures  to  support  the  comment.  To  use  this  field,  cHck 
on  the  “Browse”  button  to  find  the  path  for  the  file  the  supplement  is  in  and  se¬ 
lect  the  file.  It  wdll  be  moved  to  the  server. 

Review  Comment:  Comments  are  entered  into  this  field.  Text  can  be  copied 
from  a  word  processor  and  pasted  into  the  comment.  The  recommended  upper 
level  for  this  field  is  approximately  1,000  characters.  This  field  is  required. 

Lessons  Learned:  If  the  comment  was  a  problem  or  discovery  that  needs  to  be 
shared  with  others,  the  user  may  make  the  comment  a  Lesson  Learned.  If  the 
Lessons  Learned  value  is  set  to  “yes,”  an  intermediate  form  is  displayed  to  collect 
Lessons  Learned  information.  The  details  for  submitting  a  Lessons  Learned 
form  are  given  later  in  this  chapter. 

Value  Engineering:  If  the  Value  Engineer  Item  value  is  set  to  “yes,”  the  com¬ 
ment  is  automatically  mailed  to  the  person  indicated  as  the  Value  Engineer  for 
the  project.  Unlike  the  Lessons  Learned  option,  no  additional  comments  or 
forms  are  required  prior  to  the  submittal. 
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Edit  Comments 

Editing  comments  in  DrChecks  al¬ 
lows  a  user  to  make  changes  to  any 
open  comment  that  has  not  been  re¬ 
viewed  by  a  designer.  Figure  30 
shows  the  process  steps.  When  edit¬ 
ing  a  comment,  the  project  name 
must  first  be  chosen  by  clicking  on 
the  project  name  in  Part  1. 

In  Part  2  the  review  containing  the 
comment  must  be  chosen.  If  the 
user  is  unsure  which  review  the 
comment  is  in,  he/she  can  look  to  the 
right  of  the  grid  where  it  shows  the 
number  of  comments  pending.  If  a 
number  other  than  zero  is  in  the 
pending  coluntm,  the  review  contains 
revisable  comment(s).  After  the  re¬ 
view  has  been  chosen,  a  user  will 
then  proceed  to  Part  3  (Figure  31)  to 
view  all  revisable  comments  located 
in  the  review. 

In  Part  4  (Figure  32),  changes  to  the 
comment  cein  be  made  or  the  com¬ 
ment  can  be  deleted  completely.  To 
update  a  comment  only,  the  “No,  Do 
NOT  Delete”  option  needs  to  be  se¬ 
lected.  In  Part  5  a  user  receives  con¬ 
firmation  of  the  update. 

Project  Name:  The  project  name  is 
the  standard  project  reference  name. 
In  “Edit  Comment”  the  project  con¬ 
tains  the  review  where  comments 
will  be  edited.  This  field  is  required. 


the  comment  to  be  edited.  This  field 
is  required. 


Figure  30.  Process  of  editing  comments. 


Review  Name:  To  edit  a  comment 
in  a  review,  the  user  needs  to  select 
the  name  of  the  review  that  contains 
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Figure  31 .  Edit  Comments  Part  3. 
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Edit  Comments,  Part  4  of  5  a* 

Use  the  form  below  to  edit  or  delete  your  comment.  Managers  may  edit  aU  comments.  Screener  may  edit 
comments  of  those  assigned  to  them.  Reviewers  may  only  edit  their  comments. 
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Mechanical 
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Spec  Section:  |15400,  Plumbing,  General  Purpose 
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Sheet  * 
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Detail:  * 
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Reference:  » 

Document  i - 
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Figure  32.  Edit  Comments  Part  4. 
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Document  Type:  The  document  type  can  be  defined  as  the  part  of  the  project 
the  added  comment  affects.  For  example,  if  a  user  wants  to  add  a  comment  to 
say  “the  specifications  were  incorrect,”  he/she  would  choose  “Specifications”  from 
the  dropdown  list.  If  the  correct  document  type  is  not  listed,  the  user  needs  to 
choose  “Other.”  This  field  is  required. 

Comment’s  Discipline:  The  comment  discipline  defines  the  area  of  the  task. 
For  example,  if  the  user’s  comment  was  that  more  outlets  are  needed,  the  com¬ 
ment  disciphne  wovild  be  “Electrical.”  If  a  certain  disciphne  cannot  be  foimd  in 
the  list,  the  user  needs  to  choose  “Other.”  It  is  reasonable  to  assume  one  user 
can  use  more  than  one  discipline  during  a  review.  This  field  is  required. 

Spec  Section:  When  the  user  needs  to  refer  to  the  project,  he/she  can  enter  a 
specification  reference.  The  specification  reference  helps  the  reviewer  identify 
the  individual  project  specification  of  the  comment. 

Drawing  Sheet:  The  “Drawing  Sheet”  field  is  a  reference  to  an  architectural 
drawing.  For  example,  if  a  user  wanted  to  show  all  outlets  in  a  building,  the 
drawing  sheet  covdd  reference  the  drawing  that  shows  the  outlets. 

Drawing  Detail:  The  “Drawing  Detail”  field  is  a  reference  to  a  collection  of  ar¬ 
chitectural  drawings.  If  the  user  wants  a  reviewer  to  see  a  certain  sheet  in  a  col¬ 
lection,  he/she  can  reference  the  collection  containing  the  sheet. 

Code  Reference:  Federal  laws  or  regulations  may  be  referenced  in  the  “Code 
Reference”  field  is  necessary.  For  example,  if  a  user  wants  to  reference  the  law 
that  specifies  how  many  fire  extinguishers  are  required,  the  code  reference  would 
show  where  to  find  the  law. 

Document  Reference:  If  the  user  references  a  document  either  for  a  code  or 
specification  detail,  this  field  provides  a  place  to  store  the  reference. 

Attachment:  When  adding  a  comment,  a  user  can  use  this  field  to  add  supple¬ 
mental  comments  or  pictures  to  support  the  comment.  To  use  this  field,  click  on 
the  “Browse”  button  to  find  the  path  for  the  file  the  supplement  is  in  and  select 
the  file.  It  will  be  moved  to  the  server. 

Review  Comment:  Comments  are  entered  into  this  field.  Text  can  be  copied 
from  a  word  processor  and  pasted  into  the  comment.  The  recommended  upper 
level  for  this  field  is  approximately  1,000  characters.  This  field  is  required. 


ERDC/CERL  SR-01-20 


55 


Designer  Review 

Once  a  comment  has  been  entered,  a 
designer  needs  to  review  it  and  add 
his/her  own  comments.  This  occvirs 
on  the  “Designer  Chk”  screen.  Fig- 
iire  33  shows  the  process  steps. 

In  Part  1,  the  user  should  click  on 
the  name  of  the  project  that  contains 
comments  to  be  reviewed.  After 
clicking  on  the  project  name,  the 
user  chooses  the  review,  comment 
type,  and  discipline  in  Part  2. 

In  Part  3,  the  user  wiU  be  presented 
with  a  report  that  shows  comment 
information.  Clicking  on  the  “ID” 
nximber  to  the  left  of  the  comment 
will  take  the  user  to  Part  4,  which 
shows  where  the  comments  will  be 
placed  (Figures  34  and  35).  Concur¬ 
rence/no  concurrence  with  the  com¬ 
ment  should  also  be  specified. 

After  receiving  a  confirmation  screen 
in  Part  5,  the  user  needs  to  cUck  on 
the  [OK]  button  to  go  back  to  Part  3 
and  add  additional  comments. 

Project  Name:  The  project  name  is 
the  standard  project  reference  name. 
In  “Designer  Chk”  the  project  named 
contains  the  review  where  comments 
will  be  reviewed.  This  field  is  re¬ 
quired. 


Figure  33.  Process  of  design  review. 
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Figure  35.  Design  Review  Part  4  (continued). 
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Review  Phase:  To  review  a  comment,  the  user  selects  the  name  of  the  review 
for  which  he/she  wishes  to  review  a  comment.  This  field  is  required. 

Comment  Type:  The  comment  type  describes  the  stage  of  the  comment.  For 
example,  a  new  comment  is  considered  “pending,”  but  another  reviewer  might 
want  to  see  pending  comments.  Instead  of  the  new  reviewer  viewing  aU  com¬ 
ments,  he/she  can  choose  to  view  all  pending  conunents  in  the  comment  type  list 
box.  This  is  a  required  field. 

Specific  Discipline:  The  specific  disciphne  defines  the  area  of  the  task.  For 
example,  if  the  user’s  comment  was  about  needing  more  outlets  added,  the  com¬ 
ment  discipline  would  be  “Electrical.”  If  a  certain  discipline  cannot  be  found  in 
the  list,  he/she  will  need  to  choose  “Other.”  This  field  is  reqTiired. 

Spec  Section;  When  the  iiser  needs  to  refer  to  the  project,  he/she  can  enter  a 
specification  reference.  The  specification  reference  helps  the  reviewer  identify 
the  individual  project  specification  of  the  comment. 

Specific  Sheet:  The  “Specific  Sheet”  field  is  a  reference  to  an  architectural 
drawing.  This  field  is  not  a  reqriired,  but  it  is  the  eqioivalent  of  the  “Drawing 
Sheet”  in  “Add  Comment.” 

Specific  Detail:  The  “Drawing  Sheet”  field  is  a  reference  to  a  collection  of  ar¬ 
chitectural  drawings.  For  example,  if  the  user  wanted  to  show  all  outlets  in  a 
building,  the  drawing  sheet  could  reference  the  drawing  that  shows  the  outlets. 

Comment  Evaluation:  In  the  comment  evaluation  area  there  are  three  parts. 
First,  the  user  needs  to  specify  if  he/she  agrees  or  disagrees  with  the  comment. 
If  no  action  is  required,  he/she  could  mark  the  comment  as  information  only. 
Second,  the  user  needs  to  specify  how  the  project  scope  is  affected;  however,  this 
is  an  optional  field.  Third,  the  user  comments  on  why  he/she  agrees  or  dis¬ 
agrees.  This  field  is  required. 

Attachment  File;  When  adding  a  comment,  the  user  can  use  this  field  to  add 
supplemental  comments  or  pictmes  to  explain  the  comment  better.  To  use  this 
field,  chck  on  the  “Browse”  button  to  find  the  path  for  the  file  the  supplement  is 
in.  The  attachment  of  the  file  will  be  moved  to  the  server. 
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Designer  Import 

A  designer  can  import  a  comment  in  the  “Designer  Import”  screen.  If  a  user 
wants  to  enter  comments  located  in  a  different  file,  it  is  possible  to  import  those 
comments  to  any  available  review  in  a  project.  If  a  user  wants  to  see  all  com¬ 
ments  for  a  review,  the  [View  all  comments...]  button  should  be  clicked.  Figure 
36  shows  the  process  steps.  To  import  a  comment,  the  project  name  needs  to  be 
specified  by  clicking  on  the  project  name  in  Part  1. 


Figure  36.  Process  of  design  import. 
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Once  the  project  is  selected  and  the  user  has  proceeded  to  Part  2  (Figure  37),  the 
review  phase,  the  designer  to  review  the  conunent,  and  the  file  path  where  the 
comment  is  located  should  all  be  specified. 

If  the  file  path  is  correct,  the  upload  will  be  confirmed  in  Part  3. 

Project  Name:  The  project  name  is  the  standard  project  reference  name.  In 
“Designer  Import”  the  project  name  is  the  project  that  contains  the  review  from 
which  comments  will  be  imported.  This  field  is  required. 

Review  Phase:  To  import  a  comment,  a  user  selects  the  name  of  the  review 
where  the  imported  comment  will  be  placed.  This  field  is  required. 

File  Upload:  To  import  a  file,  the  designer  will  need  to  specify  the  path  for  the 
file  where  the  comment  can  be  found.  A  designer  import  can  be  uploaded  to  any 
review  phase,  unlike  “Import  Comment”  where  comments  can  be  imported  only 
to  the  last  review.  This  field  is  required. 

Designer  Select:  The  user  selects  a  designer  name  from  the  dropdown  list. 
Names  located  in  the  list  are  designers  assigned  for  the  project.  This  field  is  re¬ 
quired. 
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Figure  37.  Designer  Import  Part  2. 
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Backcheck  Comments 

Once  a  designer  has  reviewed  a  comment,  it  needs  to  be  backchecked.  Back- 
checking  allows  updating  a  comment  statxis  to  closed  or  open,  or  to  withdraw  the 
comment  altogether.  Figure  38  shows  the  process  steps.  In  Part  1  of  the  “Back- 
check”  screen,  the  user  chooses  the  project  to  backcheck.  The  review  in  which  a 
comment  is  located  must  be  chosen  by  clicking  on  the  review  name  in  Part  2.  A 
graph  that  holds  the  comment  information  is  presented  in  Part  3.  This  shows 
various  details  about  the  comment.  Part  4  (Figures  39  and  40)  is  where  the 
backcheck  is  entered.  The  user  clicks  on  the  “ID”  number  of  the  comment  to  be 
taken  to  the  backcheck  screen.  In  Part  5  the  user  clicks  the  [OK]  button  to  con¬ 
firm  the  backcheck. 

Project  Name:  The  project  name  is  the  standard  project  reference  name.  In 
“Backcheck  Comments,”  the  project  name  is  the  project  that  contains  the  review 
where  comments  will  be  backchecked.  This  field  is  required. 

Review  Phase:  To  backcheck  a  comment,  the  user  selects  the  name  of  the  re¬ 
view  containing  the  comment.  This  is  a  required  field. 

Comment  Status:  When  backchecking  a  comment,  the  user  specifies  whether 
the  comment  is  still  open,  closed,  or  will  be  amended  and  reviewed  again.  This 
field  is  required  and  defaults  to  “item  open.” 

Comment:  If  the  item  is  still  open  or  needs  to  be  amended,  the  user  may  want 
to  provide  an  explanation  for  the  open  status.  The  comment  is  an  optional  field 
and  is  not  required. 
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Figure  38.  Process  of  backcheck  comments. 
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Backcheck  Comments,  Part  4  of  5  f 

Review  the  continent  and  de signet's  evaluation  below,  and  view  any  attachments  provided.  When  ready, 
complete  the  backcheck  form  at  the  bottom  of  this  page.  If  you  don't  want  to  make  changes,  use  your  browsers 
back  button  to  select  another  comment.  '•*  I 
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Figure  39.  Backcheck  Comments  Part  4. 
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Figure  40.  Backcheck  Comments  Part  4  (continued). 
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New  Lesson 


Lessons  learned  are  problems  found  or  new  information  that  could  be  shared 
with  other  users.  Lessons  are  assigned  to  certain  people  for  their  approval  or 
disapproval.  Figure  41  shows  the  process  steps. 
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To  add  a  Lesson  Learned,  the  user  specifies  the  type  of  project,  type  of  customer, 
and  where  the  project  is  located.  These  specifics  are  selected  on  Part  1  of  the 
“New/  Update”  screen  (Figure  42). 

In  Part  2  (Figure  43),  the  category  code,  customer,  location,  discipline,  spec  sec¬ 
tion,  reason,  topic,  effects,  lesson  title,  problem,  solution,  and  file  attachments 
should  also  be  specified.  Clicking  on  the  [Submit]  button  takes  the  user  to  Part 
3. 

Part  3  is  where  the  user  receives  confirmation  that  the  lesson  has  been  sent  and 
notification  that  the  POC  will  send  the  user  an  email  regarding  the  lesson.  To 
print  a  hardcopy  of  this  page,  right-click  the  mouse  button  and  select  “Print” 
irom  the  popup  menu.  The  [Close  Page]  button  at  the  bottom  completes  the  sub¬ 
mission. 

Project  Category:  When  creating  a  lesson,  the  user  needs  to  choose  a  project 
category  that  shows  what  lesson  activities  are  involved.  MILCON  codes  will 
show  tasks  needed  for  a  specific  facility.  The  Civil  Works  category  code  will 
show  activities  not  broken  down  into  specific  facilities  or  tasks.  The  HTRW 
category  code  will  show  task-specific  activities  that  may  include  handling  dan¬ 
gerous  materials.  Other  codes  will  show  activities  for  local  facilities.  This  field 
is  required. 
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Figure  42.  New  Lesson  Part  1. 
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Submit  New,  Part  1  of  3 

Select  from  each  of  the  three  categories  that  best  match  your  nexr  submission. 


1.  General  Pnqect  Categories: 

Category  Code:  |  tf  approp  riate,  flag  as  CAT  CODE  specific: 

CUenf  I  If  appropriate  flag  as  CUSTOMER  criteria: 

Location;  |  If  appropriate,  flag  as  LOCATION  specific:  Jjj 


2.  Lesson  Categories: 


Disc^iine  : 
Spec  Section: 


1  Select  the  discipline  to  review  your  item;  ^ 


3.  Describe  Lessons  Learned  Effects: 


P  Error  F  Omission  F  Coordlination 

F  Functional  Design  F  Technical  Design  F  Construction 
F  Operations 

F  Cost  F  Time  F  Quality  F  Scope 


Figure  43.  New  Lesson  Part  1  (continued). 


Customer  Categories:  While  creating  a  lesson,  the  user  will  need  to  choose 
the  customer  category  that  shows  the  project  customer.  Army  customers  are 
branches  of  the  U.S.  Army.  Non-Army  Military  Customers  are  the  branches  of 
the  military  not  included  tmder  Army  Customers.  Other  Government  Agencies 
are  customers  that  work  for  the  U.S.  Government  and  are  not  included  in  the 
mihtary.  Foreign  Governments  are  non-U.S.  governments  doing  business  with 
the  DrChecks  agency.  Other  customers  are  not  U.S.  Government  or  military 
specific.  This  field  is  required. 


Location  Categories:  While  creating  a  lesson,  the  user  chooses  the  location 
category  to  show  where  the  project  is.  Outside  categories  will  show  the  names  of 
various  foreign  coimtries.  District  Specific  Sites  will  show  nearby  locations.  The 
“Within  U.S.”  category  will  list  names  of  all  U.S.  states.  This  field  is  required. 


Cat  Code:  The  Cat  Code  is  a  more  specific  Civil  Works  HTRW,  or  Military  cate¬ 
gory  depending  on  what  Project  Category  Code  was  chosen.  If  the  category  was 
Civil  Works,  the  user  can  choose  an  activity  not  meant  for  specific  facilities  or 
tasks.  If  the  category  was  HTRW,  the  user  can  choose  a  task-specific  activity 
that  may  include  handling  dangerous  materials.  If  the  category  was  Military^ 
the  user  can  choose  a  task  needed  for  a  specific  facility. 
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Customer:  The  customer  is  a  more  specific  customer  category  code.  The  cus¬ 
tomer  refers  to  the  group  or  organization  requesting  the  project.  Army  custom¬ 
ers  are  the  branches  of  the  U.S.  Army.  Federal  Government  Agencies  are  cus¬ 
tomers  that  work  for  the  U.S.  Government  and  are  not  included  in  the  mifitary. 
Foreign  Governments  are  non-U.S.  governments  doing  business  with  the 
DrChecks  agency.  Local  Customers  are  not  U.S.  Govenunent  or  military  spe¬ 
cific.  Other  Mifitary  Customers  are  the  branches  of  the  mifitary  that  cannot  be 
included  under  Army  Customers. 

Location:  The  location  targets  the  specific  area  where  the  project  is  taking 
place.  After  a  customer  has  chosen  a  larger  area  such  as  a  foreign  site,  a  local 
site,  or  a  U.S.  state,  a  site  within  that  larger  area  needs  to  be  chosen. 

Discipline:  The  comment  discipline  defines  the  area  of  the  task.  For  example, 
if  the  user’s  comment  was  that  more  outlets  are  needed,  the  comment  discipline 
would  be  “Electrical.”  If  a  certain  discipline  cannot  be  foimd  in  the  fist,  the  user 
will  need  to  choose  “Other.”  This  field  is  required. 

Spec  Section:  When  a  user  needs  to  refer  to  the  project,  he/she  can  enter  a 
specification  reference.  The  specification  reference  helps  the  reviewer  identify 
the  individual  project  specification  of  the  comment. 

Lesson  Learned  Effects:  When  creating  a  new  lesson,  the  user  needs  to  spec¬ 
ify  the  effects  on  the  lesson.  Three  ways  to  specify  are  by  determining  the  rea¬ 
son,  topic,  and  effects.  The  reason  can  be  described  as  the  cause  of  the  error  or 
effect.  The  topic  is  a  required  field  that  specifies  in  what  stage  of  the  design  or 
operation  the  lesson  occurred.  The  effect  specifies  what  type  of  effect  occmred. 
This  field  is  required. 

Lesson  Learned  Description:  The  Lesson  Learned  Description  should  include 
the  title  of  the  lesson,  the  problem,  the  suggestion  of  chauige,  and  the  solution. 
The  problem  field  should  contain  the  complete  description  of  the  problem  found. 
The  suggestion  of  change  allows  a  user  to  recommend  a  change  to  fix  the  prob¬ 
lem.  The  change  could  be  made  in  manuals,  regulations,  or  specifications.  The 
description  of  the  solution  should  go  in  the  solution  field.  This  field  is  required. 

File  Attachments:  When  entering  the  problem  and  solution  of  the  lesson,  it 
may  be  necessary  to  include  supplemental  materials.  The  supplemental  materi¬ 
als  can  be  attached  by  using  the  “Problem  Backup”  and  “Solution  Backup”  fields. 
Both  fields  need  the  file  path  specified.  These  fields  are  not  required. 
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POC  Evaluate  Lessons 

After  the  lesson  has  been  submitted,  the  POC  needs  to  evaluate  the  lesson  or  re¬ 
assign  it  to  another  POC.  Figure  44  shows  the  process  steps. 

To  view  the  details  about  a  particular  lesson,  the  ID  number  beside  it  needs  to  be 
chosen  in  Part  1. 


All  comments  about  the  lesson  au*e  located  in  Part  2  of  “POC  Evaluate”  (Figures 
45  and  46).  If  he/she  does  not  want  to  approve  the  lesson,  it  can  be  sent  to  an¬ 
other  POC. 


Figure  44.  Process  of  POC  Evaluate. 
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[  3  PyChecksyCLL  -  Microsoit  Inteinet  Exploier 


Agfa»|€3  hHpi/Zwww  biJdcfsnet0fg/dcheck*yvef«)n2/main.cfm?RESETSITE-CECER 


Click  ►  for  menu 

►  Help 

^  Account  Info 

►  Projects 

►  Reviews 
^  Lessons 

New  Lesson 
PQC  Evaluate 

Review'Update 

Access  Rights 

►  Find 

►  Admin 


Manual 

Tech  Support 
DrC hecks  P reject 


DrChecks/CLL  Demo 


Evaluate  Lessons,  Part  2  of  3 

Use  the  form  below  to  eraluate  the  pending  LL.  When  you  submit  the  form  date,  the  author  of  the  item  will 
be  notified  of  changes  you  have  made,  if  reassigning  an  item,  then  both  the  item's  author  and  the  new 
discipline  POCs  win  be  notified. 


1.  General  Context: 
Cat  Code  Specific: 
Client 

Location  Specific: 

2.  Lesson  Categories: 
Disc^&ie*: 

Spec  Section: 

3.  Lesson  Effects: 
Reason: 

Topic: 

LSects:  i 

4.  Descr^tion: 

Lesson  Iitie*: 

Problem*: 

4 


Administrative  -  Odicr 


(not  an  error,  omission,  or  coordination  issue) 

Technical  Design 

(not  a  cost,  time,  quality,  or  scope  issue) 

Air  Entrainment 

Please  add  10%  air  entrainment  to  sidewalk  concrete  to  limit  cold 


- **" 


_ _ Kil_ 


Figure  45.  POC  Evaluate  Part  2. 


Click  ►  for  menu 


^  Help 

►  Account  Info 

►  Projects 

►  Reviews 
Lessons 
New  Lesson 
POC  Evaluate 

Review/Update 

Access  Rights 

►  Find 

^  Admin 


M9inij.ai 

Tech  Support 
DtChecks  Pruiect 


DrChecks/CLL  Demo 


Problem  Backup:  (problem  bada^  file  not  provided) 

Solution  Badaq):  (problem  bada^  file  not  provided) 

Submitted  by  Mr  Bill  East  (voice:  217-352-6511  x6710  \ 


Your  Reconmifindation  on  Lesson  ID  321: 

Action*:  [Select  eji  ACTION  option  below  ^ 

Assign  To:  |  If  (re)assigning  Item  for  review:  pick  POC  j 

Discussion/Justification*:  F 


Prior  Assignment  by: 

Rior  Assignment  to:  SYSTEM  ADItHNISTRATORS 

Mr  Sample  Manager,  jmoll@rcesupportcom,  800-428-4357 


Figure  46.  POC  Evaluate  Part  2  (continued). 
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After  the  evaluation  is  complete,  clicking  the  [Submit]  button  will  take  the  user 
to  Part  3,  where  he/she  receives  a  confirmation  message  of  the  submittal. 

Action:  After  a  lesson  has  been  chosen,  the  user  will  need  to  decide  how  he/she 
will  hgindle  the  lesson.  The  user  can  choose  to  approve  the  lesson,  deny  the  les¬ 
son,  reassign  it  to  a  different  POC,  or  request  backup  from  the  author.  This  is  a 
required  field. 

Assign  To:  If  the  user  wants  to  reassign  the  lesson  to  another  POC,  he/she 
needs  to  select  a  name  from  the  “Assign  To”  dropdown  Ust.  The  names  on  the 
list  are  administrators  for  the  site. 

Discussion/Justification:  If  the  POC  wants  to  evaluate  the  lesson,  he/she  will 
need  to  specify  an  action  and  then  discuss  the  reason  for  the  action  in  the  “Dis- 
cussion/Jxistification”  field.  This  field  is  required  regardless  if  the  lesson  has 
been  evaluated  or  reassigned. 
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Review/Update  Lesson 


To  change  information  about  the  lesson  submitted  or  delete  the  lesson  alto¬ 
gether,  the  user  can  do  so  by  using  the  “Review/Update”  screen.  Figure  47  shows 
the  process  steps. 


Figure  47.  Process  of  review/updating  a  lesson. 


ERDC/CERL  SR-01-20 


Part  1  will  show  a  list  of  all  of  the  pending,  unapproved,  and  approved  lessons. 
If  the  user  clicks  on  an  unapproved  or  approved  lesson,  a  screen  showing  all  de¬ 
tails  of  the  lesson  will  appear  in  Part  2  (Figure  48). 

Cat  Code:  The  Cat  Code  is  a  more  specific  Cml  Works,  HTRW,  or  MUitary 
category  depending  on  what  Project  Category  Code  was  chosen.  If  the  category 
was  Civil  Works,  a  user  can  choose  an  activity  not  meant  for  specific  facilities  or 
tasks.  If  the  category  was  HTRW,  a  user  can  choose  a  task-specific  activity  that 
may  include  handling  dangerous  materials.  If  the  category  was  Military,  a  user 
can  choose  a  task  needed  for  a  specific  facility. 


Customer:  The  customer  is  a  more  specific  customer  category  code.  It  refers  to 
the  group  or  organization  requesting  the  project.  Army  customers  are  the 
branches  of  the  U.S.  Army.  Federal  Government  Agencies  are  customers  that 
work  for  the  U.S.  Government  and  are  not  included  in  the  military.  Foreign 
(governments  are  non-U.S.  governments  doing  business  with  the  DrChecks 
agency.  Local  Customers  are  not  U.S.  Government  or  military  specific.  Other 
Military  Customers  are  the  branches  of  the  military  that  cannot  be  included  tm- 
der  Army  Customers. 


Figure  48.  Review/Update  Lessons  Part  2. 
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Location:  The  location  targets  the  specific  area  where  the  project  is  taking 
place.  After  a  customer  has  chosen  a  larger  area  such  as  a  foreign  site,  a  local 
site,  or  a  U.S.  state,  a  site  within  that  larger  area  needs  to  be  chosen. 

Discipline:  The  comment  discipline  defines  the  area  of  the  task.  For  example, 
if  the  user’s  comment  was  that  more  outlets  are  needed,  the  comment  discipline 
woxild  be  “Electrical.”  If  a  certain  discipline  cannot  be  found  on  the  list,  the  user 
will  need  to  choose  “Other.”  This  field  is  reqtdred. 

Spec  Section:  When  a  user  needs  to  refer  to  the  project,  he/she  can  enter  a 
specification  reference.  The  specification  reference  helps  the  reviewer  identify 
the  individual  project  specification  of  the  comment. 

Lesson  Learned  Effects:  The  effects  on  the  lesson  can  be  specified  by  deter¬ 
mining  the  reason,  topic,  and  effects.  The  reason  can  be  described  as  the  cause 
of  the  effect  or  error.  The  topic  is  a  reqviired  field  that  specifies  in  what  stage  of 
the  design  or  operation  the  lesson  occurred.  The  effect  specifies  what  type  of  ef¬ 
fect  occurred.  This  field  is  required. 

Lesson  Learned  Description:  The  Lesson  Learned  Description  should  include 
the  title  of  the  lesson,  the  problem,  the  suggestion  of  change,  and  the  solution. 
The  problem  field  shotild  contain  the  complete  description  of  the  problem  fovmd. 
The  suggestion  of  change  allows  a  user  to  recommend  a  change  in  order  to  fix  the 
problem.  The  change  could  be  made  in  the  manuals,  regulations,  or  specifica¬ 
tions.  The  description  of  the  solution  should  go  in  the  solution  field.  This  field  is 
required. 

File  Attachments:  When  entering  the  problem  and  solution  of  the  lesson,  it 
may  be  necessary  to  include  supplemental  materials.  The  supplemental  materi¬ 
als  can  be  attached  by  using  the  “Problem  Backup”  and  “Solution  Backup”  fields. 
Both  fields  need  the  file  path  specified.  These  fields  are  not  required. 
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Access  Rights 


If  only  certain  people  are  to  review  the  lesson  submitted,  the  access  rights  may 
be  changed  to  accommodate  new  reviewers.  Figure  49  shows  the  process  steps. 


To  assign  access  rights,  the  user  shoxild  highlight  his/her  name  in  the  box  and 
click  on  the  [Add]  button  in  Part  1  (Figure  50).  This  will  add  the  name  to  the  re¬ 
viewer  list.  In  Part  2  the  user  confirms  that  the  name  has  been  added.  CHcking 
on  the  [Return]  button  returns  the  user  to  Part  1  of  “Access  Rights.” 


74 


ERDC/CERLSR-01-20 


I^DrChecks/CLL  -  Miciosoft  Inleinet  EKploier 

IS 


€]  http:/>'www,buildersnetof9/drcheck5/vef«on2/maiacfm?RESETSlTE=CECER 


Clicks  for  menu 

>  Help 

^  Account  Info 

►  Projects 
^  Revievws 

Lessons 
New  Lesson 
PQC  Evaluate 

Review/Update 


User  Manual 

Tech  Support 
DrChecks  Project 


DrChecks/CLL  Demo 


Lessons  POC's  Access,  Part  1  of  2  ak  2 

Use  the  form  beloM'  to  assign  lessons  leemed  POC's  for  each  design  disc^line.  Reviewer's  responsible  for  » ^ 
evaluating  pending  lessons  le^ed  are  displayed  by  dis  cipline.  Select  one  or  more  (using  the  CTRL  key)  1 1 

p arsons  in  a  disc^line,  then  cHck  the  'Add  or  '<  Def  button  to  change  access.  ^ 


. 

Am  clirrently  asslgiaed  POC's. 


Acoustics 

Not  Assigned; 

Mr  test  customer 
MrRickDahnke  ^ 
Mr  Jeff  Moll  iJ 
Mr  Bruce  Rives 
Ms  Jana  Shuler 

Architectural 

Not  Assigned: 

I  Mr  test  customer  ri 


Assigned: 

Mr  Bill  East 
Mr  Jeff  Kirby  ; 


Assigned: 
I  Mr  Bill  East 


m  w;,  m  «r  a  ^  ^ 

!'■  ^  -sr-  -ss;  ;«■  *g:  a  .  n  . 


Figure  50.  Lesson  Access  Rights  Part  1. 


Unassigned  Users;  A  person’s  name  is  in  the  default  unassigned  box  until 
he/she  has  been  given  certain  access  rights.  Each  box  of  imassigned  users  are 
teams  or  individuals  that  meet  the  criteria  of  the  assignment  type  chosen.  These 
individuals  or  groups  are  also  divided  into  reviewers,  designers,  managers,  and 
customers.  This  field  is  required. 

Assigned  Users:  An  assigned  user  has  access  rights  to  a  certain  project.  Each 
time  a  tiser’s  name  appears  in  the  assigned  box  gives  access  rights  in  that  divi¬ 
sion.  For  example,  if  a  user  is  assigned  as  a  reviewer  and  designer,  the  only  ac¬ 
cess  rights  the  user  has  are  reviewer  and  designer  rights.  This  field  is  required. 
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Quick  Find  Comments 

If  a  user  wants  to  find  a  certain  comment  without  having  to  search  through  the 
whole  database,  he/she  can  use  the  “Find  Comments”  process.  Figure  51  shows 
the  process  steps. 

Part  1  of  the  comment  search  (Figure  52)  provides  a  quick  method  to  access  a 
specific  comment  or  comments  by  key  words.  The  search  will  be  executed 
against  either  “your”  comments  or  everyone’s  comments,  depending  upon  the 
specifications.  The  search  is  not  case  sensitive. 


Once  the  search  is  complete,  a  list  of  all  comments  found  in  the  search  will  be 
presented  in  Part  2  (Figure  53).  The  top  section  of  the  page  lists  the  criteria 
used  during  the  search  and  the  number  of  cases  returned.  If  the  correct  com¬ 
ment  was  not  found,  the  user  may  want  to  click  on  the  link  “Quick”  to  go  back  to 
Part  1. 


Part  1 :  Enter  search  criteria 


Search  for  \ 
everyone’s  V— — 

comments?  / 


Search  for 
keyword{s)  In 
all  comments 


Are  any 
comments 
found? 


Provide  ‘no 
match 
found' 
messaoe 


Search  for 
everyone’s 
comments? 


Search  for 
user’s 
comments 


Are  any 
comments 
found? 


Search  for 
comments 


Retrieve  all 
comments 


Provide  ‘no 
match 
founcf 
message 


Are  any 
comments 
found? 


Part  2:  Display  comments 


Retrieve 

comments 


Provide  ‘no 
match 
found’ 
messaoe 


Part  2:  Display  comments 


Figure  51.  Process  of  quick  find  comments. 
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Figure  52.  Quick  Find  Comments  Part  1. 
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Click  ►  for  ineriij 
^  Help 

^  Account  Info 

►  Projects 

►  Reviews 

►  Lessons 
▼  Find 

Comments 

Lessons 
View  Archive 

Site  Status 

Army  Puhs 

COE  Pubs 
COE  Standards 

Viewers  Plur|ins 

►  Admin 


iJser  Manual 

Tech  Sunport 
DrChecks  Project 


DrChecks/CLL  Demo 


Quick  Find,  Part  2  of  2  tkk 

Review  the  selected  comments  below.  Sort  by  cHcldng  on  column  heading.  To  find  a  specific  comment  press 
CTRL-i^  and  enter  a  ke3rword  word  or  comment  ID  number.  Print  using  the  button  on  the  bottom  of  this  page. 
Go  to  the  quick  or  advanced  search  page. 

Tavr  search  retmed  SSO  Cenmenls. 


Note:  More  than  50  comments  were  found.  To  increase  processing  speed  contact  information  for  last 
modified,  designer  evaluation  and  reviewer  backcheck  not  displayed.  Click  hSSS.  to  display  all  contact 


07600,  Flashing  and  Sheet 
Metal 


(not 

identifie<^ 


i  (^ot  identifiei^ 


Architectural 


Ensure  that  the  gauge  of  the  sheet  metal  is  to  standard. 

Submittad  by  Mr  Bill  East  (voice:  217-352^31 1  36710  email  b-eastracecer.amiv.mih  on  21-May-98. 

Designer  will  check  and  resolve  as  noted  on  2a-Jan“00: 

This  is  an  item  that  the  project  manager  should  address  due  to  its  scope  and  schedule  intact. 
Note:  This  item  may  impact  the  project's  scope! 

Note:  This  item  may  impact  the  projects  final  costf 

Note:  This  item  may  impact  the  projects  overall  coKq)letion  time! 

Item  remains  open  as  of  28-.Aug-00: 

The  A/E  Should  do  something  about  this  item.  They  have  and  now  everything  is  okay  (date) 


07600,  Flashing  and  Sheet 


(not 


(not  identified^ 


Figure  53.  Quick  Find  Comments  Part  2. 


Keyword(s):  To  do  a  quick  search  on  comments,  a  user  may  want  to  specify  a 
word  that  can  be  fovmd  in  the  desired  comment.  If  two  or  more  words  can  be 
specified,  the  search  will  look  for  those  two  words  as  a  combination.  These  words 
can  also  be  separated  by  a  comma  to  search  for  either  word. 

Whose  Comments:  If  a  user  wants  to  search  on  his/her  own  comments,  he/she 
needs  to  specify  the  “Only  Mine”  option;  otherwise,  the  “Everyone’s”  option 
should  be  selected.  If  selected,  the  search  will  be  for  all  users.  This  field  is  re- 
qiiired. 
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Advanced  Find  Comments 

To  do  a  more  advanced  search,  the 
user  clicks  on  the  “Advanced”  link  to 
go  to  a  screen  where  he/she  can  specify 
the  project,  customer,  or  location. 
Figure  54  shows  the  process  steps. 


Figure  54.  Process  of  advanced  find  comments. 


When  the  search  criteria  are  filled  in, 
clicking  on  the  [Continue]  button  in 
Part  1  (Figure  55)  will  start  the 
search.  Based  on  the  criteria  specified 
in  Part  1  of  the  advanced  search,  the 
user  will  be  able  to  narrow  down  the 
search  criteria  in  Part  2  (Figure  56). 

Once  all  desired  fields  have  been  filled 
in,  clicking  on  [Continue]  in  Part  2  fin¬ 
ishes  the  search.  Part  3  of  the  ad¬ 


vanced  search  shows  the  search  re¬ 
sults  based  on  the  search  criteria 
specified  in  Part  2. 

Project  Category  Code:  The  pro¬ 
ject  category  code  will  show  what  the 
project  activities  involve.  The  pro¬ 
ject  category  code  can  be  one  of  three 
t3^es.  The  Civil  Works  category 
code  shows  activities  not  broken 
down  into  specific  facilities  or  tasks. 
The  HTRW  category  code  shows 
task-specific  activities  that  may  in¬ 
clude  handling  dangerous  materials. 
Military  codes  show  tasks  needed  for 
a  specific  facility. 

Customer  Categories:  The  cus¬ 
tomer  category  shows  the  project 
customer.  Army  customers  are 
branches  of  the  U.S.  Army.  Non- 
Army  Military  Customers  are  the 
branches  of  the  military  not  included 
under  Army  Customers.  Other  (Gov¬ 
ernment  Agencies  are  those  custom¬ 
ers  who  work  for  the  U.S.  Govern¬ 
ment  and  are  not  included  in  the 
military.  Foreign  (Governments  are 
non-U.S.  governments  doing  busi¬ 
ness  with  the  DrChecks  agency. 
Other  customers  are  not  U.S.  (Gov¬ 
ernment  or  military  specific. 
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Figure.  55.  Advanced  Find  Comments  Part  1. 
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Advanced  Find,  Part  2  of  3  Hsk  “ 

Identify  the  specific  type  of  comment  you  need  using  the  form  below.  Add  4  comma  between  each  kejrwotd  or  0(1 
key  phrase.  Go  to  quick  or  back  to  advanced  search.  § 


l.Keyword(s):  | 

2.  Who  by:  |  Any  Users  Comments  Jr 


3.  Comment  Type:  |  All  Comments 


4.  Project:  [Any  Project 
5.  Comment’s  Discipline:  |  Other 
6.  Spec  Section:  | 

7.  Sheet  Name: 


9.  Project  Category;  (not  cat  COdc  specific) 
10.  Client  (not  client  specific) 

11.  Location;  (not  location  Specific) 


'i  i  im. 


Figure  56.  Advanced  Find  Comments  Part  2. 
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Location  Categories:  The  location  category  shows  where  the  project  is.  Out¬ 
side  categories  show  the  names  of  various  foreign  countries.  District  Specific 
Sites  show  nearby  locations.  The  “Within  U.S.”  category  lists  names  of  all  U.S. 
states. 

Keyword(s):  To  do  a  qtdck  search  on  comments,  the  user  may  want  to  specify  a 
word  that  can  be  foimd  in  the  desired  comment.  If  two  or  more  words  can  be 
specified,  the  search  will  look  for  those  two  words  as  a  combination.  These  words 
can  also  be  separated  by  a  comma  to  search  for  either  word. 

Who  By:  The  “Who  By”  field  allows  a  user  to  specify  whose  comments  to  view. 
The  names  included  in  the  drop  down  list  are  users  in  the  site.  Only  one  name 
can  be  chosen  but,  if  a  name  is  not  found,  the  defaxilt  “Any  User  Lessons”  can  be 
used. 

Comment  Type:  The  comment  type  describes  the  stage  of  the  comment.  For 
example,  a  new  comment  is  considered  “pending,”  but  another  reviewer  might 
want  to  see  pending  comments.  Instead  of  the  new  reviewer  viewing  all  com¬ 
ments,  he/she  can  choose  to  view  all  pending  comments  in  the  comment  type  list 
box. 

Project:  The  project  name  is  the  standard  project  reference  name.  In  “Ad¬ 
vanced  Find”  the  project  name  is  the  project  where  the  comment  search  is  to  be 
performed. 

Comment  Discipline:  The  comment  discipline  defines  the  area  of  the  task.  If 
this  is  specified,  the  search  will  find  all  matches  for  that  discipline.  A  search  can 
also  be  done  across  all  disciplines. 

Spec  Section:  When  a  user  needs  to  refer  to  the  project,  he/she  can  enter  in  a 
specification  reference.  The  specification  reference  helps  the  reviewer  identify 
the  individual  project  specification  of  the  comment. 

Specific  Sheet:  The  “Specific  Sheet”  field  is  a  reference  to  an  architectural 
drawing.  This  field  is  not  a  required,  but  it  is  the  equivalent  of  the  “Drawing 
Sheet”  in  “Add  Comment.” 

Specific  Detail:  The  “Drawing  Sheet”  field  is  a  reference  to  a  collection  of  ar¬ 
chitectural  drawings’.  For  example,  if  a  user  wanted  to  show  aU  outlets  in  a 
building,  the  drawing  sheet  could  reference  the  specific  drawing  that  shows  the 
outlets. 
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Find  Lessons 


If  a  user  is  in  a  hurry  to  find  a  certain  lesson,  it  is  easy  to  type  in  specific  criteria 
instead  of  searching  the  database  manually.  With  the  “Find  Lesson”  process, 
this  search  can  be  done  easily.  Figure  57  shows  the  process  steps. 


Figure  57.  Process  of  finding  lessons. 


The  first  part  of  finding  lessons  is  to  specify  some  search  criteria.  A  user  can 
choose  to  specify  project  type,  customer  type,  and  location  type  in  Part  1  (Figure 
58). 


In  Part  2  (Figure  59),  the  user  can  narrow  a  search  further.  Depending  on  what 
was  chosen  in  Part  1,  the  category  types  are  narrowed  down.  Also,  the  user  can 
add  additional  search  criteria  such  as  who  the  lesson  was  created  by,  comment 
discipline,  and  lesson  learned  effects.  These  are  not  required,  however. 
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View  Archive 

Site  Status 
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Approved  Lessons,  Part  1  of  3  Hsk  ■ 

Select  the  overall  categories  for  the  lessons  learned  you  want  to  find.  Note  that  only  approved  lessons  learned  r 
are  returned. 


1.  Project  Type:  |  Not  project  spedfic 


2.ClientType:  [Not  client  specific 
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Figure  59.  Find  Lessons  Part  2. 
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Approved  Lessons,  Part  2  of  3  Hsk 

Identify  the  specific  type  of  approve d  lessons  learned  you  need  using  the  form  below.  Add  a  coinma 
between  each  keyword  or  key  phrase.  Go  to  back  to  enable  or  select  different  categories. 

1.  Keywordl(s);  j 
2.  Spec  Section:  j 

S.Commentfs  - - - tti 


Discipline:  I'"'"'”  ^ 

4.  Who  by:  |  Shuler.  Jana  ~  ^ 

5.  Project:  [Any  Project  2 

d.CatCode:  | All  Categories  jj 
7.  Reason:  F  Error  F  Omission  F  Coordination 

8  Topic  ^  ^^ctional  Design  F  Technical  Design  F  Construction 
F  Operations 

I  9.  Effects:  F  Cost  F  Time  F  Quality  F  Scope 

...XT, I  ^  m  ^  i-  i  w.  ^  ris  -  w  m  s:  *•;  ^  -m  ■%: 


The  search  results  based  on  the  specified  criteria  are  shown  in  Part  3.  To  con¬ 
duct  another  search,  the  user  clicks  on  the  “Back”  link  to  return  to  Part  1. 


Project  Type:  A  Project  Type  shows  what  the  lesson  involves.  MILCON  codes 
show  tasks  needed  for  a  specific  facility.  The  Civil  Works  category  code  shows 
activities  not  broken  down  into  specific  facilities  or  tasks.  The  HTRW  category 
code  shows  task-specific  activities  that  may  include  handling  dangerous  materi¬ 
als.  Other  codes  show  activities  for  local  facilities. 

Customer  Type:  The  customer  category  shows  the  project  customer.  Army 
customers  are  the  branches  of  the  U.S.  Army.  Non-Army  Military  Customers  are 
the  branches  of  the  military  not  included  under  Army  Customers.  Other  Gov¬ 
ernment  Agencies  are  customers  that  work  for  the  U.S.  Government  and  are  not 
included  in  the  military.  Foreign  Governments  are  non-U.S.  governments  doing 
business  with  the  DrChecks  agency.  Other  customers  are  not  U.S.  Government 
or  military  specific. 

Location  Type:  The  location  type  shows  where  the  project  is.  Outside  catego¬ 
ries  show  the  names  of  various  foreign  countries.  District  Specific  Sites  show 
nearby  locations.  The  “Within  U.S.”  category  lists  names  of  all  U.S.  states. 

Keyword(s):  To  do  a  quick  search  on  comments,  a  user  may  want  to  specify  a 
word  that  can  be  found  in  the  desired  comment.  If  two  or  more  words  can  be 
specified,  the  search  looks  for  those  two  words  as  a  combination.  These  words 
can  also  be  separated  by  a  comma  to  search  for  either  word. 

Spec  Section:  When  a  user  needs  to  refer  to  the  project,  he/she  can  enter  in  a 
specification  reference.  The  specification  reference  helps  the  reviewer  identify 
the  individual  project  specification  of  the  comment. 

Comment  Discipline:  The  comment  discipline  defines  the  area  of  the  task.  If 
this  is  specified,  the  search  will  find  all  matches  for  that  discipline.  A  search  can 
also  be  done  across  all  disciplines. 

Who  By:  The  “Who  By”  field  allows  a  user  to  specify  whose  comments  to  view. 
The  names  included  in  the  drop  down  list  are  users  in  the  site.  Only  one  name 
can  be  chosen  but,  if  a  name  is  not  found,  the  default  “Any  User  Lessons”  can  be 
used. 

Project:  The  project  name  is  the  standard  project  reference  name.  In  “Ad¬ 
vanced  Find”  the  project  name  is  the  project  where  the  comment  search  is  to  be 
performed. 

Cat  Code:  The  Cat  Code  is  a  more  specific  Civil  Works,  HTRW,  or  Military 
category  depending  on  what  Project  Category  Code  was  chosen.  If  the  category 
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was  Civil  Works,  a  user  can  choose  an  activity  not  meant  for  specific  facilities  or 
tasks.  If  the  category  was  HTRW,  a  user  can  choose  a  task-specific  activity  that 
may  include  handling  dangerous  materials.  If  the  category  was  Military,  a  user 
can  choose  a  task  needed  for  a  specific  facility. 

Lesson  Learned  Effects:  The  effects  on  the  lesson  can  be  specified  in  three 
ways  by  determining  the  reason,  topic,  and  effects.  The  reason  can  be  described 
as  the  cause  of  the  effect  or  error.  The  topic  is  a  required  field  that  specifies  in 
what  stage  of  the  design  or  operation  the  lesson  occurred.  The  effect  specifies 
what  t3rpe  of  effect  occurred. 

List  Archive 

After  a  user  has  archived  a  project,  it  is  possible  to  refer  back  to  it  later  by  using 
“View  Archive.”  To  archive,  the  user  clicks  on  the  project  ID  located  to  the  left  of 
the  project  name.  Once  the  ID  is  clicked,  the  user  will  be  presented  with  all  ar¬ 
chived  reviews  for  the  project  and  locations  of  the  archive.  To  view  an  archive, 
the  address  needs  to  be  clicked  to  automatically  return  to  the  archive.  Figure  60 
shows  the  process  steps,  and  Figures  61  and  62  show  the  associated  program 
menus. 


Figure  60.  Process  of  listing  an  archive. 
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Figure  61 .  View  Archive  Part  1 . 


DiCheck$/CLL  -  Microso^l  internet  Explorei 


mmn 


http;  //WWW.  buildef  snet  org/dchecks/vec  swnZ/main.  cfm?RE  S  ETSITE*CECER 


Clicks  for  menu 


Help 

Account  Info 
Projects 
Reviews 
Lessons 
▼Find 

Comments 

Lessons 
View  Archive 

Site  Status 

Army  Pubs 

COE  Pubs 
COE  Standards 

VIcwers/Pluqins 


DrChecks/CLL  Demo 


List  Archive  heJi 

This  pege  contains  links  to  aU  projects  tiles  in  your  office's  project  archive.  Comments  are  saved 
according  to  review  and  disc^Hne.  Each  discipline  has  its  own  separate  HTML  file.  Keywords  searches 
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Figure  62.  View  Archive  Part  2. 
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Site  Status 


The  “Site  Status”  screen  allows  a  user  to  view  various  summaries  about  projects 
and  comments,  T^e  discipline,  category,  location,  and  customer  reports  can  also 
be  viewed.  If  reviewing  a  summary,  the  user  will  be  presented  with  a  graph  that 
shows  the  summary  statistics.  If  viewing  a  report,  the  user  will  need  to  specify 
the  criteria  of  the  report.  Figure  63  shows  the  process  steps,  and  Figure  64 
shows  the  associated  program  menu. 
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Click  ►  for  menu 
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Site  Status  hui  “ 

This  page  contains  the  first  try  at  a  'digital  dashboard^  that  will  allow  managers  and  interested  others  to  ^ 
gauge  the  overall  performance  of  a  DtChecks  site.  J] 

|'5 

No  average  metrics  have  been  developed  at  this  time,  however,  in  the  future  there  you  should  be  able  to  ^ 
coir^are  your  results  to  that  of  all  other  DrChecks  users.  ^ 


Office  Comment  Summary  go  *  * 

M  anagers'  Pf oj  e  ct  Summary  go  ^  ^ 

Managers'  Comment  Summary  go  , 

■3! " 

Reviewers'  Project  Summary  go  ^  * 

Clients'  Comment  Summary  go  3?  ^ 

De  signers'  C  omment  Summary  go 


QA  Discipline  Report  go 
QA  Category  Report  go 
QA  Customer  Report  go 
QA  Location  Report  go 


Figure  64.  Site  Status  Part  1. 
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Update  Category  Codes 

Category  codes  define  the  type  of  funding  a  project  will  be  under  or  what  type  of 
activity  the  project  is.  The  four  category  codes  are  Military,  Civil  Works,  HTRW, 
and  local  category  codes.  Figure  65  shows  the  process  steps. 

To  update  or  add  a  new  category  code,  a  user  should  specify  the  code  by  clicking 
on  a  type  in  the  pick  box  and  clicking  on  the  [Continue]  button  in  Part  1. 

A  grid  of  the  cxirrent  category  codes  will  be  presented  in  Part  2  (Figure  66).  To 
add  a  category  code,  the  user  fills  in  information  about  the  new  category  and 
clicks  on  the  [Add]  button.  This  places  the  new  code  into  the  grid  with  the  oth¬ 
ers.  To  delete  a  category  code,  the  user  clicks  on  the  [Del]  button.  Deleting  a 
category  code  will  cause  all  links  to  it  to  be  removed. 

Cat  Code:  The  Cat  Code  is  a  more 
specific  Civil  Works,  HTRW,  or  Mili¬ 
tary  category,  depending  on  what 
P*roject  Category  Code  was  chosen. 
If  the  category  was  Civil  Works,  a 
user  can  choose  an  activity  not 
meant  for  specific  facilities  or  tasks. 
If  the  category  was  HTRW,  a  user 
can  choose  a  task-specific  activity 
that  may  include  handling  danger¬ 
ous  materials.  If  the  category  was 
Military,  a  user  cem  choose  a  task 
needed  for  a  specific  facility.  This 
field  is  reqviired. 


Parent:  To  show  one  row  is  under, 
subordinate  to,  or  part  of  another 
row,  the  user  should  enter  the  top- 
level  ID  number  in  the  “Parent”  data 
field  of  the  child  row.  This  field  is 
required. 


Figure  65.  Process  of  updating  cat  codes. 
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Figure  66.  Update  Cat  Codes  Parti. 


Level:  The  level  number  shows  in  what  row  the  category  code  can  be  foxmd.  If 
the  level  is  higher  than  1,  the  code  is  subordinate  code  from  an  upper  layer.  The 
top  level  is  1.  This  field  is  required. 


Number:  A  category  code  can  be  referenced  by  a  unique  number  or  character. 
This  required  field  could  be  alphanumeric  (a  combination  of  letters  and  num¬ 
bers). 

Name:  For  all  names,  this  field  provides  the  description  of  the  Cat  Code  that  is 
associated  with  the  number.  If  the  description  is  changed  for  a  number,  it  will 
be  reflected  in  all  comments  or  lessons  where  it  is  referenced.  This  field  is  re¬ 
quired. 
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Update  Customers 


Customers  in  DrChecks  are  considered 
to  be  for  whom  the  individual  works. 
To  add  a  customer  or  update  the  cus¬ 
tomer  specifics,  a  user  needs  to  go  to 
“Customers.”  Figure  67  shows  the 
process  steps. 


Figure  67.  Process  of  updating  customer 
codes. 


The  type  of  customer  should  be  cho¬ 
sen  in  Part  1.  The  customer  types 
available  are:  Army  Customers, 
Federal  Government  Agencies,  For¬ 
eign  Governments,  Local  Customers, 
and  Other  Military  Customers. 

Once  the  customer  type  is  chosen, 
the  user  clicks  on  [Continue]  to  be 
presented  with  the  current  customer 
codes.  To  add  a  customer  code  in 
Part  2  (Figure  68),  fill  in  the  infor¬ 
mation  about  the  new  customer  and 
click  on  the  [Add]  button.  The  new 
code  will  be  placed  into  the  grid  with 
the  other  codes.  A  customer  code  in 
this  screen  can  be  deleted  by  click¬ 
ing  on  the  [Del]  button.  This  will 
cause  all  customer  links  to  it  to  be 
removed. 

Customer  Category  Code:  The 
customer  category  code  wiU  show  to 
whom  the  project  pertains.  Army 
customers  are  the  branches  of  the 
U.S.  Army.  Federal  Government 
Agencies  are  customers  that  work 
for  the  U.S.  Government  and  are  not 
included  in  the  military.  Foreign 
Governments  are  non-U.  S.  govern¬ 
ments  doing  business  with  the 
DrChecks  agency.  Local  customers 
are  not  U.S.  Government  or  military 
specific.  Other  Military  Customers 
are  the  branches  of  the  military  not 
included  under  Army  Customers. 
This  field  is  required. 
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Figure  68.  Update  Customers  Part  2. 


Parent:  To  show  one  row  is  vinder,  subordinate  to,  or  part  of  another  row,  the 
user  should  enter  the  top-level  ID  number  in  the  “Parent”  data  field  of  the  child 
row.  This  field  is  required. 

Level:  The  level  number  shows  in  what  row  a  customer  category  can  be  found. 
If  the  level  is  higher  than  1,  the  code  is  subordinate  code  from  an  upper  layer. 
The  top  level  is  0.  This  field  is  required. 


Number:  A  customer  category  can  be  referenced  by  a  unique  number  or  charac¬ 
ter.  This  field  is  required. 


Name:  For  all  names,  this  field  provides  the  description  of  the  Customer  Cate¬ 
gory  that  is  associated  with  the  number.  If  the  description  is  changed  for  a  num¬ 
ber,  it  will  be  reflected  m  all  comments  or  lessons  where  it  is  referenced.  This 
field  is  required. 
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Update  Disciplines 

Disciplines  describe  the  type  of  job  required.  The  types  of  jobs  can  be  mechani¬ 
cal,  architectural,  etc.  If  a  discipline  is  not  shown  or  information  about  a  disci¬ 
pline  needs  to  be  changed,  this  can  be  done  in  the  “Disciplines”  screen  that  shows 
all  cmrent  disciplines  and  the  corresponding  information.  Figure  69  shows  the 
process  steps. 

If  a  user  desires  to  add  a  discipline,  he/she  needs  to  enter  the  information  in  the 
boxes  at  the  top  in  Part  1  (Figure  70).  The  user  clicks  on  the  [Add]  button  to 
save  these  changes.  Once  it  is  added,  it  shows  in  the  “Discipline”  grid.  To 
change  information  about  the  disciplines,  the  user  makes  the  necessary  changes 
and  then  clicks  on  the  [Change]  button.  A  discipline  can  also  be  deleted  by  click¬ 
ing  the  [Del]  button  on  the  left  of  the  grid.  Deleting  a  discipline  will  cause  all 
links  to  the  discipline  to  be  removed. 
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Figure  70.  Update  Disciplines  Part  1. 


Parent:  To  show  one  row  is  under,  subordinate  to,  or  part  of  another  row,  the 
user  should  enter  the  top-level  ID  number  in  the  “Parent”  data  field  of  the  child 
row.  This  field  is  required. 

Level:  The  level  number  shows  in  what  row  a  disciphne  category  can  be  found. 
If  the  level  is  higher  than  1,  the  code  is  subordinate  code  from  an  upper  layer. 
The  top  level  is  0.  This  field  is  required. 

Number:  A  discipline  can  be  referenced  by  a  unique  number  or  character.  This 
field  is  required. 


Name:  For  all  names,  this  field  describes  the  discipline  that  is  associated  with 
the  number.  If  the  description  is  changed  for  a  number,  it  will  be  reflected  in  all 
comments  or  lessons  where  it  is  referenced.  This  field  is  required. 
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Update  Document  Types 


To  add,  delete,  or  make  changes  to  doc  types,  a  user  will  need  to  go  to  the  “Up¬ 
date  Doc  Types”  screen.  The  document  type  is  the  part  of  the  project  comments 
effect.  Figure  71  shows  the  process  steps. 


To  add  a  “doc  type”  in  Part  1,  the  name  of  the  new  “doc  type”  should  be  entered 
into  the  first  box  shown  imder  “Add  Single  Discipline”  and  the  [Add]  button 
clicked  (Figure  72).  The  new  doc  type  is  placed  at  the  bottom  of  the  list.  To 
change  a  doc  type,  the  user  needs  to  locate  the  correct  type,  make  the  necessary 
changes,  and  click  on  the  [Change]  button  to  update.  Deleting  a  doc  type  can 
also  be  done  by  locating  the  desired  type  in  the  list  and  clicking  on  the  [Del]  but¬ 
ton  located  to  the  left  of  the  type  ID  ntunber.  The  user  will  not  be  warned  that 
deleting  a  type  deletes  associated  links. 

Name:  For  all  names,  this  field  describes  the  Doc  Type  associated  with  the 
number.  If  the  description  is  changed  for  a  number,  it  will  be  reflected  in  all 
comments  or  lessons  where  it  is  referenced.  This  field  is  required. 
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Figure  72.  Update  Doc  Types  Part  1. 


Delete  Lessons 


To  delete  an  approved  lesson,  a  user  goes  to  the  “Delete  Lessons”  screen.  Keep 
in  mind  that  the  deletion  cannot  be  xmdone.  Figure  73  shows  the  process  steps. 


Figure  73.  Process  of  deleting  a  lesson. 
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In  Part  1  (Figure  74),  the  lesson  can  be  chosen  in  two  ways.  Search  for  a  lesson 
by  typing  in  the  lesson  ID  ntunber  and  clicking  on  [Find],  or  specify  the  project 
type,  customer  type,  or  location  type  and  click  on  the  [Continue]  button.  These 
fields  are  not  required,  however. 

In  Part  2  (Figure  75),  the  user  will  be  allowed  to  narrow  the  search  by  entering 
more  criteria.  Criteria  can  be  project,  location,  and  customer  types.  These  are 
not  required,  however. 

Part  3  shows  all  lessons  that  meet  the  criteria  specified  in  Parts  1  and  2.  The 
xiser  finds  the  lesson  to  delete  and  clicks  on  [Delete]  located  to  the  right  of  each 
lesson.  The  closest  match  will  be  foimd.  Deleting  a  lesson  causes  all  links  to  the 
lesson  to  be  removed. 


Project  Category:  A  project  category  shows  what  the  lesson  will  involve, 
MILCON  codes  will  show  tasks  needed  for  a  specific  facility.  The  Civil  Works 
category  code  will  show  activities  not  broken  down  into  specific  facilities  or  tasks. 
The  HTRW  category  code  will  show  task-specific  activities  that  may  include 
handling  dangerous  materials.  Other  codes  wiU  show  activities  for  local  facili¬ 
ties. 


Figure  74.  Delete  Lessons  Part  1 . 
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Figure  75.  Delete  Lessons  Part  2. 


Customer  Type;  The  customer  category  shows  the  project  customer.  Army 
customers  are  the  branches  of  the  U.S.  Army.  Non-Army  Military  Customers  are 
the  branches  of  the  military  not  included  imder  Army  Customers.  Other  Gov¬ 
ernment  Agencies  are  customers  that  work  for  the  U.S.  Government  and  are  not 
included  in  the  military.  Foreign  Governments  are  non-U.S.  governments  doing 
business  with  the  DrChecks  agency.  Other  customers  are  not  U.S.  Government 
or  military  specific. 

Location  Type:  The  location  type  shows  where  the  project  is.  Outside  catego¬ 
ries  show  the  names  of  various  foreign  covmtries.  District  Specific  Sites  shows 
nearby  locations.  The  “Within  U.S.”  category  lists  all  names  of  U.S.  states. 

Ke3^ord(s);  To  do  a  quick  search  on  comments,  a  user  may  want  to  specify  a 
word  that  can  be  foimd  in  the  desired  comment.  If  two  or  more  words  can  be 
specified,  the  search  will  look  for  those  two  words  as  a  combination.  These  words 
can  also  be  separated  by  a  comma  to  search  for  either  word. 

Spec  Section;  When  a  user  needs  to  refer  to  the  project,  he/she  can  enter  a 
specification  reference.  The  specification  reference  helps  the  reviewer  identify 
the  individual  project  specification  of  the  comment. 
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Comment  Discipline:  The  comment  discipline  defines  the  area  of  the  task.  If 
this  is  specified,  the  search  will  find  all  matches  for  that  discipline.  A  search  can 
also  be  done  across  all  disciplines. 

Who  By:  The  “Who  field  allows  a  user  to  specify  whose  comments  to  view. 
The  names  in  the  dropdown  list  are  users  in  the  site.  Only  one  name  can  be  cho¬ 
sen  but,  if  a  name  is  not  foxmd,  the  default  “Any  User  Lessons”  can  be  used. 

Project:  The  project  name  is  the  standard  project  reference  name.  In  “Delete 
Project”  the  project  contains  reviews  where  comments  can  be  foimd. 

Cat  Code:  The  Cat  Code  is  a  more  specific  Civil  Works,  HTRW,  or  Military 
category  depending  on  what  Project  Category  Code  was  chosen.  If  the  category 
was  Civil  Works,  a  user  can  choose  an  activity  not  meant  for  specific  facilities  or 
tasks.  If  the  category  was  HTRW,  a  user  can  choose  a  task-specific  activity  that 
may  include  handling  dangerous  materials.  If  the  category  was  Military,  a  user 
can  choose  a  task  needed  for  a  specific  facility. 

Lesson  Learned  Effects:  The  effects  on  the  lesson  can  be  specified  in  three 
ways  by  determining  the  reason,  topic,  and  effects.  The  reason  can  be  described 
as  the  cause  of  the  effect  or  error.  The  topic  is  a  required  field  that  specifies  in 
what  stage  of  the  design  or  operation  the  lesson  occurred.  The  effect  specifies 
what  type  of  effect  occurred. 
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Update  Locations 


Location  codes  define  the  project  location.  The  three  location  codes  are  Foreign 
Country  Codes,  Local  Sites,  and  U.S.  State  Names.  Updating  a  location  code  is 
used  to  enter  new  locations  or  edit  existing  location  codes.  Figure  76  shows  the 
process  steps. 


To  update  or  add  a  new  location  code  in  Part  1,  a  user  specifies  the  type  by  click¬ 
ing  on  the  type  in  the  pick  box  and  clicking  on  the  [Continue]  button. 

A  grid  of  the  current  location  codes  will  be  presented  in  Part  2  (Figure  77).  To 
add  a  code,  a  user  fills  in  information  about  the  new  location  and  clicks  on  [Add]. 
This  places  the  new  code  into  the  grid  with  the  other  location  codes.  A  location 
code  can  be  deleted  by  clicking  on  the  [Del]  button.  The  Foreign  Coimtry  Codes 
and  the  U.S.  State  names  are  standard  sets  and  typically  do  not  require  changes 
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by  the  administrator.  The  Local  Sites  section  is  designated  as  the  area  for  com¬ 
pany-specific  locations.  Additions  to  locations  typically  should  be  limited  to  the 
Local  Sites.  Names  can  be  edited  with  no  impact  on  link  information. 

Location  Category  Code:  The  location  category  code  shows  where  the  project 
is.  Foreign  Country  Codes  show  the  names  of  various  foreign  countries.  Local 
Sites  shows  nearby  locations.  U.S.  State  Names  lists  all  names  of  U.S.  states. 
This  field  is  required. 

Parent:  To  show  one  row  is  under,  subordinate  to,  or  part  of  another  row,  the 
user  should  enter  the  top-level  ID  nmnber  in  the  “Parent”  data  field  of  the  child 
row.  This  is  a  required  field. 

Level:  The  level  number  shows  in  what  row  the  location  category  can  be  foimd. 
If  the  level  is  higher  than  1,  the  code  is  subordinate  code  from  an  upper  layer. 
The  top  level  is  0.  This  field  is  required. 

Number:  A  location  can  be  referenced  by  a  imique  number  or  character.  This 
field  is  required. 

Name:  To  reference  a  code  on  many  different  screens,  it  is  easier  to  remember  a 
name  rather  than  a  number  or  combination  of  characters.  Such  a  name  can  be 
entered  in  the  “Name”  field.  This  is  a  required  field. 
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Figure  77.  Update  Locations  Part  2. 
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Update  Offices 

The  “Offices”  screen  shows  information  about  the  office  and  allows  a  user  to  add 
or  make  changes  accordingly.  If  a  user  wants  to  view  a  list  of  office  passwords, 
he/she  clicks  on  the  “List”  link.  Figure  78  shows  the  process  steps.  To  add  an 
office  in  Part  1,  the  name  of  the  office  should  be  entered,  the  access  rights  should 
be  assigned,  and  the  parent  ID  needs  to  be  specified  (Figure  79).  To  change  the 
access  rights  of  the  office,  the  user  clicks  on  the  “yes”  or  “no”  located  imder  each 
column. 

To  see  more  information  about  the  office,  the  user  needs  to  click  on  the  ID  lo¬ 
cated  in  Part  2  on  the  left  side  of  the  grid.  Additional  changes  can  be  made  here. 
Clicking  on  the  [Update]  button  updates  the  changes.  The  [Update  and  Clone] 
button  uses  the  office  as  a  template  to  build  sub-offices.  Clicking  on  the  [Delete] 
button  deletes  an  office  completely. 

Parent  Office  ID;  To  show  one  row  is  under,  subordinate  to,  or  part  of  another 
row,  the  user  should  enter  the  top-level  ID  number  in  the  Parent  data  field  of  the 
child  row.  This  field  is  required. 

Office  Name:  In  the  “Office  Name”  field,  the  user  enters  the  office  name  as  it 
wovdd  appear  in  reports.  This  field  is  required. 

Default  User  Permissions:  The  “Default  User  Permissions”  are  those  access 
rights  a  user  automatically  has  when  he/she  registers  under  an  office  name.  An 
office  can  have  more  than  one  assigned  permission.  This  field  is  required. 

Fkey  Parent:  This  field  is  also  known  as  the  “Parent  Office  ID”  that  shows  one 
row  is  imder,  subordinate  to,  or  part  of  another  row.  The  user  should  enter  the 
top  level  ID  number  in  “Parent  Office  ID”  field  of  the  child  row.  This  field  is  re¬ 
quired. 

Office  Address:  The  “Office  Address”  is  a  combination  of  items.  These  items 
are  “OfcStreet,”  “OfcBox,”  “OfcStop,”  “OfcCity,”  “OfcState,”  and  “OfcZip.”  These 
fields  are  not  required. 
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Figure  79.  Update  Offices  Part  1. 


OfcPhone:  The  telephone  number  is  where  a  user  can  be  contacted  regarding 
DrChecks  questions  or  concerns.  Thfe  default  telephone  number  is  that  of  the 
user’s  office.  A  user  can  keep  this  number  or  change  it  to  a  telephone  number 
that  can  also  be  reached  for  DrChecks  questions  or  concerns. 

OfcFAX;  The  fax  munber  is  the  number  where  a  copy  of  a  doctunent  can  be  sent 
electronically  without  using  a  computer. 

OfcEmail:  If  an  office  has  a  single  address  that  receives  email,  this  field  is 
where  a  user  can  enter  the  email  address.  This  field  is  not  required,  however. 
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Update  Users 

The  “Update  User”  page  provides  administrators  the  option  to  add,  edit,  or  delete 
user  records.  It  is  restricted  to  key  information  necessary  to  hold  a  place  for  the 
user  until  they  register  and  fill  in  their  own  critical  data.  The  user  table  is  pre¬ 
sented  in  a  grid  used  throughout  DrChecks  data  entry  and  management.  Chck- 
ing  on  the  “Report”  link  at  the  top  of  the  page  is  a  way  to  view  user  information. 
Figure  80  shows  the  process  steps. 


Figure  80.  Process  of  updating  users.  . 
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Update  Welcome 

The  “Welcome”  page  is  used  to  modify  the  appearance  of  the  initial  DrChecks 
page.  It  includes  the  program  title,  company  information,  and  the  general  mes¬ 
sage  presented  on  arrival  (including  the  message  presented  to  new  users).  In 
several  parts  of  this  page,  it  is  possible  to  use  HTML  code  to  provide  more  inter¬ 
esting  displays  to  the  users;  however,  it  is  best  to  keep  the  display  as  clean  and 
simple  as  possible  to  support  easier  reading.  Figure  81  shows  the  process  steps. 


In  Part  1  of  the  “Update  Welcome”  process  (Figure  82),  a  user  may  change  the 
system  name,  the  top  and  bottom  messages,  and  the  footer.  This  is  done  with 
HTML  code. 
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'3(^rChecks/CLL  -  MicrosoN  Internet  Explorer 


hi tp: //WWW. buflder sneL or g/drchecks/ver sion2/mah cfmTRESETSITE «CE CE R 


DrChecks/CLL  Demo 


r  r\i;view^ 

^  Lessons 
►  Find 
^  Admin 
CatCodes 

Ciistoiners 

Disciplines 

Doc  Types 
Delete  Lessons 

Locations 

Offices 

Users 


Update  Help 

User  Manual 

Tech  Support 
DrChecks  Proiect 


Update  Site^^^  of  1  "  ’ 

y  Use  the  fotm  below^to  make  changes  yowDiCheckfi/ClU  site.  Yon  may  include  HTML  coding  in  the  v 
memo  fields.  Click  the  button  at  the  bottom,  of  the  page  to  i^date  your  site.  You  may  hare  to  dose  your 
bfoveser  and  re-enter  the  site  to  see  some  changes.  ' \  ^ 

Changes  to  the  data  below'  effects  ybvw:  entire  DiChecks/CIX  site.  Do  i^tusc  double  t^uotabon  Tnarksk 

1*  System  Name:  jDrChecks/ClL  Derno  '  '  • 

2.  Visit^  Top  Message:  '  ■ 

<P  CLASS- "Bri:LCOHETOPTEXT''>The  Design’ Revieix  and  Checking  ^ 

System  (DrChecks)  empowers  project  teams  to  improve  design 
quality  through  an  integrated  web-based  business  process. 

DrChecks  assists  review  conment  authors  and  designers  to 
reach  agreement  on  the  resolution  of  each  improvement  J  .. 

suggestion.  Reports  allow  users  to  see  others'  work,  || 

review  the  progress,  identify  reluctant  participants,  and  % 
identify  issues  that  impact  scope,  tirae,  or  cost.  The  goal 
of  DrChecks  is  to  support  the  successful  resolution  of  .z* 

problem  issues  before  project  milestones  are  reached. </P>  if 
<CENTER><HR  NOSHADE  COLOR-NAVY  iJIDTH-400></CENTER>  '  ^  \  .J. 

<P  CLASS- "HELCOHETOPTEXT''>Integrated  within  DrChecks  is  the  |  ^ 

Corporate  Lessons  Learned  (CLL)  system.  CLL  allows  team  T \\ 

“I  s  '3.-  Sr  ^  1  'M  f  f  i.:^  if:  t  n 


Figure  82.  Update  Welcome  Parti. 


System  Name:  Provide  the  company  name  and  contact  information  in  this 
area.  The  company  name  is  plotted  above  the  general  content  frame  for 
DrChecks.  Use  the  browser  refresh  button  to  see  changes  in  the  company  name 
after  changes  have  been  made. 

Top  and  Bottom  Messages:  Both  of  the  message  boxes  enable  the  user  to  edit 
•  the  content  of  displayed  messages.  Since  each  message  is  an  HTML  message 

box,  the  browser  will  format  the  text  to  fit  the  page.  If  lists  or  bullets,  text  size 
or  color  changes,  centering,  or  other  formatting  commands  are  desired,  they 
must  be  inserted  with  HTML  coding.  This  field  is  required. 

Footer:  The  information  contained  on  the  bottom  of  the  page  is  the  contact  in¬ 
formation  for  the  site.  The  items  included  should  be  the  office  name,  office  URL 
(website),  POC  name,  POC  email  address,  and  POC  telephone  number.  This 
field  is  required. 
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4  DrChecks  Current  Usage  Statistics 

DrChecks  User  Locations 

Comments  serve  as  the  primary  measure  of  the  active  use  of  the  DrChecks  web 
site  by  the  subscriber  organizations.  During  calendar  years  1999  and  2000,  the 
number  of  subscriber  organizations  increased  from  2  to  16.  Subscribers  exist  on 
fom*  different  servers.  Korea  has  a  DrChecks  server  with  very  limited  use  of  the 
program  to  date.  Honolulu  District  has  a  server  on  which  approximately  1,600 
comments  are  stored.  The  Department  of  State  maintains  their  own  server  and 
has  over  17,000  comments  stored  online.  The  remaining  13  subscribers  are  on  a 
single  server  where  more  than  36,000  comments  are  stored  online. 


Measuring  Usage 

This  section  presents  several  graphs  of  program  use.  The  measure  used  is  the 
number  of  comments  per  month,  which  is  only  a  rough  measure  of  the  actual 
program  usage.  Statistics  of  web  use  are  available  but  have  been  excluded  from 
this  pubHcation.  It  is  difficult  to  determine  if  web  accesses  are  useftil  or  produc¬ 
tive.  Therefore,  even  though  impressive  “hit”  coimts  are  available,  the  number 
of  comments  actually  registered  against  a  review  provides  a  better  indicator  of 
use  of  the  program  to  do  actual  work.  Unfortunately,  this  measure  fails  to  ad¬ 
dress  advantages  such  as  a  review  of  online  data  through  searches.  These  uses 
contribute  to  the  hit  coimt  and  are  likely  of  significant  advantage  to  the  review¬ 
ers  and  designers  involved  in  a  project,  but  are  not  as  easily  measured. 

Figure  83  displays  comments  per  month  summed  across  all  program  users.  The 
graph  indicates  that  use  in  1999  was  limited.  During  the  first  9  months,  only 
two  districts  were  actively  recording  comments  in  the  system.  During  the  last  3 
months  of  1999,  the  Department  of  State  entered  the  group  and  used  the  system 
heavily.  In  December  1999,  the  comment  covmt  per  month  across  users  exceeded 
1,000  for  the  first  time.  Except  for  a  drop  below  1,000  in  January  2000,  the 
comment  rate  has  not  again  dropped  below  1,000  per  month.  For  all  of  year 
2000,  the  coimt  averaged  4,202  comments  submitted  per  month. 
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_ Month/Year _ 

Figure  83.  Total  comments  for  1999  and  2000  arranged  by  months. 

Comments  summed  across  subscribers  show  a  notable  saddle  in  the  plot  in  Au¬ 
gust,  September,  and  October.  This  reduction  is  expected  due  to  the  nature  of 
project  funding.  When  the  end  of  the  Federal  fiscal  year  approaches,  there  is 
typically  a  flurry  of  activity  as  funds  are  committed.  After  the  start  of  the  new 
fiscal  year,  new  funds  become  available  and  the  comment  frequency  climbs  back 
up. 

Examining  Use  Patterns  for  High*Use  Subscribers 

It  is  useful  to  review  use  patterns  in  the  charts  (Figures  84  to  87)  that  display 
comments  per  month  for  the  fo\ir  largest  users  of  the  DrChecks  program.  The 
graphs  demonstrate  the  consistent  activity  drop  between  fiscal  years  as  just 
mentioned.  Additional  features  are  worth  noting. 

The  graph  for  CELRH  -  HuntsviUe  District  (Figure  84)  indicates  that  activity  is 
msu'kedly  periodic.  Based  on  review  of  the  projects  in  that  District,  it  appears 
that  the  distribution  of  comments  relates  to  the  nature  of  the  projects  they  are 
involved  in  reviewing.  More  of  their  projects  are  larger.  Civil  Works  projects 
that  go  through  distinct  cycles  and  impact  the  workload  of  the  organization  in 
bursts.  Comment  totals  by  month  in  the  graph  demonstrate  the  effect. 

Graphs  for  CENTS  -  Seattle  District  and  for  CENAB  -  Baltimore  District  (Fig¬ 
ures  85  and  86)  demonstrate  a  smoother  activity  level  fi'om  month  to  month. 
The  majority  of  the  projects  at  both  sites  are  military  and  include  more  small 
projects  than  at  a  District  involved  with  Civil  Works  projects.  Again,  both  or¬ 
ganizations  demonstrate  the  fiscal  year  effect  discussed  initially. 
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Figure  84.  CELRH  District  totai  comments  for  1999  and  2000. 


Finally,  Figure  87  shows  the  activity  for  Department  of  State  users.  Again,  the 
effect  at  the  fiscal  year  boxmdary  is  demonstrated.  Otherwise,  their  use  pattern 
was  generally  a  steady  increase.  The  significant  activity  drop  in  the  fifth  and 
sixth  months  of  year  2000  were  a  result  of  failure  of  the  server  used  by  the  De¬ 
partment  of  State  at  that  time,  making  it  imavailable  for  recording  comments  for 
approximately  2  months.  After  this  server  was  repaired,  use  continued  to  in¬ 
crease.  Server  failure  had  a  profound  effect  on  the  activity’s  ability  to  accom¬ 
plish  work  and  reemphasized  the  need  for  a  good  plan  for  information  manage¬ 
ment  by  DrChecks  users. 


Figure  87.  Department  of  State  total  comments  for  1999  and  2000. 
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5  Conclusion  and  Future  Work 


Conclusion 

It  is  difficult  to  say  more  than  that  DrChecks  program  use  has  steadily  increased 
since  the  program  was  made  available  for  general  use.  Additional  subscribers 
will  be  added  during  the  current  fiscal  year,  and  it  is  expected  that  both  existing 
and  new  users  will  add  significant  data  to  the  current  database.  Further,  as  Dis¬ 
tricts  adopt  DrChecks  as  their  only  review  tool  and  include  all  projects,  a  num¬ 
ber  of  additional  measures  should  be  of  great  value.  In  particular,  the  data  will 
be  evaluated  to  determine  average  length  of  reviews,  length  of  comments,  com¬ 
ment  resolution  time,  and  additional  parameters. 


Future  Work 


Development  of  DrChecks  Version  3  is  nearing  completion.  A  significant  change 
in  user  interface  will  be  fielded  along  with  additional  features  comprised  by  the 
Design  Quality  Suite  of  tools.  Incorporated  with  Version  3  wiU  be  the  Request 
for  Information  (RFI)  Module.  RFI  will  support  the  management  and  resolution 
of  bidder  inqiiiries  during  the  construction  bidding  process.  In  addition,  the  Cri¬ 
teria  Management  System  (CMS  2)  will  be  included  to  automatically  review  any 
DrChecks  potential  lessons  learned  for  criteria  impact.  Copies  of  potential  les¬ 
sons  will  be  routed  to  a  local  POC  for  review.  If  it  is  determined  that  the  poten¬ 
tial  lesson  learned  does  have  a  criteria  impact,  the  POC  will  identify  the  appro¬ 
priate  criteria  for  automatic  emails  to  notify  (1)  the  national  criteria  manager 
that  a  request  for  review  has  been  forwarded  and  (2)  the  original  submitter  that 
his/her  suggestion  has  been  forwarded  for  review  and  action. 
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